面向对象第一单元总结

前言

　　从接触OO课程至今，我已经完成了三次OO的关于表达式求导的做业，也是时候对本身的编程做业进行一次总结了。鉴于三次做业从指导书上描述差异不大，所以将主要针对第三次关于表达式求导的代码进行分析。

程序结构的分析

对程序架构的描述：

　　对于OO（即面向对象编程），我目前为止一直采起的策略是尽量地对目标进行封装，但鉴于一，二两次做业并无多大地工程量，所以我并无采起严格地分类，即输入类，输出类，sin类等的分类方式，第一次做业只有一个类，而第二次也只分了Expressioninput，ExpressionProcess，ItemProcess和Poly四个类，从类的命名能够看出，我分类的思路并非对一个单纯的物体对象进行封装，我封装的对象是一个过程，这其实源于我对面向对象的理解。我认为的OO强调的是一个类只须要给与和给出信息，就算合格，可是不少时候，给出的信息也须要统合才能真正起到做用，就好像火箭的每一个模块都造好了，但仍须要一条流水线来完成火箭的组装同样，而流水线自己也能够做为一个对象进行封装，这就是我前两次做业的架构思想。而第三次做业随着难度的增长，我在封装流水线的基础上进一步细化，以下图。

　　从上图，我细化了封装的求导部分，拆解成单独的加法式（包含在Inputcheck类里），乘法式，括号式，以及各种通常因子的处理，整体上对类分划分我的仍是比较满意，但问题出在加法式处理这一部分，从上图（Statics插件分析的结果）看，很明显Inputcheck这一负责处理输入格式问题的类行数远多于其它类，形成这一现象的缘由是，我把加法式类写在了这个类里面，正确的作法应该是采用继承，或类的声明与调用。此外，加法式类彻底与其余类脱节，致使其内含有大量的杂碎功能，包括但不限于格式的检验，括号的匹配，这样的设计是彻底违背封装的初衷的。

经典的OO度量

　　采用了IDEA的插件Metricsreloaded对第三次做业计算经典OO度量，结果以下图：

　　从上图，能够看出我在第一部分对Inputcheck的分析是彻底正确的，Inputcheck内这几个重要方法，基本复杂度高，模块设计复杂，与其余模块的耦合度高，并且难于独立地进行检查和维护，能够说至关的失败。而各种的方法广泛具备结构化较差的缺点，据我分析，缘由是我没有采用继承，由父节点负责相同的方法，而是对每一个相似的类都手动copy了一个相似的方法，模块化低下，难以维护。

程序类图

 

 　　优势：

1. 1. 基本对不一样对象进行了完全封装。
   2. 实现了经过不一样类之间的调用完成降层的求导过程
   3. 采用继承，实现了常量的屡次复用

　　 缺点：

1. 1. 没有彻底正确地设计类的种类，例如加法式类被写成了Inputcheck的一个方法
   2. 继承没有正确运用，其价值不只在继承常量，还在方法的复用
   3. 方法没有正确构建，方法之间存在重复

分析BUG

　　目前为止的三次做业，第一次在强测和互测环节均未出现BUG，下面以第二次和第三次作分析。

• 第二次做业

　　输入示例：

 

x*sin(x)*cos(x)-+-2*x^-3*sin(x)^-2*cos(x)^+3

 

　　个人错误输出：

x*cos(x)^2-x*sin(x)^2+sin(x)*cos(x)-6*x^-3*sin(x)^-cos(x)^2-4*x^-3*sin(x)^-3*cos(x)^4-6*x^-4*sin(x)^-2*cos(x)^3

　　很明显，个人错误是输出地部份内容莫名其妙地消失了，在BUG修复阶段我从新审查了程序，发现错误在这里

                temp = temp.replaceFirst("-1\\*","-");

　　这段代码本意是将每一项开始系数为“-1*”的部分省略为“-”，可是，在实际操做过程当中它的实际效果是将第一个匹配到的“-1*”省略为“-”，修改成以下便可，出现这个问题主要是没有很好的明白得到信息和要求的信息具体条件是什么。

                temp = temp.replaceFirst("^-1\\*","-");

 

• 第三次做业

 

1. 输入示例：　

cos(    (-sin    (((0)+0))))*    sin(100000000)    +    cos    ((x*    00000)    )

　　 2. 输入示例:　　

cos((cos(sin(x^3)^3)^3))^2*x^1*sin(x^2)^1

　　以上输入个人程序都会给出”WRONG FORMAT!“的错误输出，细察其缘由，问题出在Inputcheck类中的special方法上，该方法设计的初衷是为了全覆盖检测"sin()"、"cos()"内的括号内容是否合法，但在实际设计的时候并无将全部的可能涵盖在内，属于设计不全面形成的BUG。勉强能够和设计的重复性致使的设计思路混乱扯上关系，不过，归根结底，应该是设计的不完善形成的。

　　为了解决这个BUG产生的根源，应作好完善的设计档案，至少，针对须要完备性设计的程序块要有一个清晰的设计，以便审核全覆盖与否。

分析别人BUG的策略

1. 使用本身的测试集测试；
2. 分析指导书，进一步寻找可能的边界条件，构建测试样例测试
3. 对代码进行分析，针对性写测试样例

 总结和反思

　　个人第一次、第二次和第三次做业都是彻底独立的，即没有采用重构的方式，主要缘由仍是第一次和第二次重构的代价太大。第一次做业彻底只有一个类，不具有重构的价值；第二次做业与其说是面向对象的思路，不如说是面向流水线的拼接思路，本质上走的仍是顺序编程的思路，一样没有重构的价值。第三次做业，将分别封装独特的类，已经具有了重构和继承的基础，在第三次做业的基础上能够继续添加条件和要求。对针对性的类，好比对乘法的拆解，彻底能够采用继承的方式，添加须要增长的因子，或者采用重构，更改拆解的方式和格式。可是，由于加法式的拆解内嵌在了Inputcheck里面，对它的重构可能会出现不可预料的结果，所以，若是不更改Inputcheck的结构，重铸加法式类，那么最好采用继承的方式重写。