OO_JAVA_表达式求导_单元总结

这里引用个，是我写的另一份博客，讲的是设计层面的问题，下面主要是对自己代码的单元总结。

程序分析

(1)基于度量来分析自己的程序结构

第一次作业

程序结构大致如图：

类图景

结构比较简单，只有三个类，分别是Main，Polynomial和PolynomialItem。

方法复杂度分析如图：

方法复杂度图景

可以见得：主要是类的构造方法和toString方法复杂度较高，因为要面面俱到。

第二次作业

程序结构大致如图：

类图景

程序结构比较简单，只有六个类。

方法复杂度如图：

方法复杂度图景

可以见得：由于是在表达式和因子的类之外建立的求导方法类，Diff类的求导和化简函数复杂度都很高；然后就是因子Factor的构造方法和toString方法以及Item的构造方法复杂度很高；再其余就是ExprProcess处理类复杂度很高。

Diff类和ExprProcess类内部都是静态方法，这样设计是来自过程式编程，采取一个函数处理不需要自己独立的属性，即不需要建立一个类，直接使用其静态方法，静态方法其主要工程用途应该是作为工厂函数，如此写作是滥用，我已经意识到了。

第三次作业

程序结构大致如图：

类图景

这张图表明，Atom与其子类是关系紧密的，其它在逻辑上较为分离的。

所有的Atom子类都继承自Atom父类，这在设计上是不可取的，依赖度太高，不应该是extends继承的真正用法。

Atom父类包含了所有子类所需属性和方法，也不合理。

方法复杂度如图：

方法复杂度图景1

首先列举一下复杂度较高都是些什么方法：

ExprProcess静态方法类，由于依旧是与第二次作业类同的组合方式，写出了这么个静态方法类，造成了单一方法巨大的复杂度，应该按照我在我开头引用的我的博客链接里的Parser的写作方法，把复杂度分散到不同Parser接口实现中，但是这基本上是我第三次作业写完了才学到的方法，所以没有运用；

AtomFactory类的两个静态方法，这是我为了集约式根据枚举类型创建子类而编写的，复杂度高情有可原；

PlusAtom和MultiAtom的Merge方法，因为处在合并同类项层次，故而要处理的类很多，所以复杂度极高，是属于可以拆分的；

Atom类内部一系列跟合并化简相关的函数，因为其写作在顶层父类Atom中，又牵涉各级子类，复杂度较高：
- couldBeMergedAroundPlus和couldBeMergedAroundMulti两个函数，我的Predicate接口，用来判断两项是否能被合并，还没有有效的构建方式，涉及子类有比较多，所以复杂度高；
- equals方法：为上述两个函数准备的，依旧是处于父类，所以方法复杂度较高；
- expand和flatMap方法：依旧是为化简准备的，但是写在父类，不可避免地发生了比较高的复杂度。

(2)分析自己程序的bug

表达式求导的第一次作业比较简单，中强测和互测没有叮出bug；

第二次作业的bug问题主要是缩略空白字符时，正则表达式漏了+号表示替换一片空白为一个空格，因此出了正确格式误判为WF；

第三次作业优化部分有很大的bug，除此之外，在正常处理部分，漏算了一条Scanner的hasNext方法会略去最后的空白字符，应该提前trim掉，改了这个bug并删去优化的调用，就修完了，也就是说正常处理部分是这一个bug。

总体来说最容易出现bug的位置还是输入处理和优化这两部分，输入是业界老大难，毕竟很难保证用户不会某一个异常输入爆掉你的程序，所以这部分处理由于思维的局限性、不连贯性，很容易出现疏漏，而优化部分，很容易因为过于复杂的逻辑产生代码中的隐蔽问题，可能简单的样例没有问题，但是稍微精心的样例就可以爆掉。。

这就说明，逻辑越内秉，越聚合在一起，就越容易出现bug，输入处理和优化都是这样。

所以设计类、接口的层次结构时就必须考虑这个问题，分散逻辑。

从树的角度，我设计的类有个很大的问题就是父类实现了所有的方法，太累赘太复杂了。。。

(3)分析自己发现别人程序bug所采用的策略

我没有采取研究别人代码或是正则的方式寻找bug，属于随心随机地写一些数据找别人的bug，因为第二次作业犯了小错误，第三次作业交了优化版本还有其它的小疏漏，应该是被分到C组这样，所以随机地构造一些数据我就找到了很多别人的bug，但是第一次作业就不行了，在结构非常简单的前提下，要找bug就必须深入细节或者是大批量测试才行。

我的主要随机构造思路就是尽可能嵌套多一些，空格随机加一些，主力寻找别人把正确格式误判为错误格式这样的bug。