OO_JAVA_表达式求导_单元总结

OO_JAVA_表达式求导_单元总结

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

程序分析

(1)基于度量来分析本身的程序结构

第一次做业

程序结构大体如图：

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

方法复杂度分析如图：

能够见得：主要是类的构造方法和toString方法复杂度较高，由于要面面俱到。

第二次做业

程序结构大体如图：

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

方法复杂度如图：

能够见得：因为是在表达式和因子的类以外创建的求导方法类，Diff类的求导和化简函数复杂度都很高；而后就是因子Factor的构造方法和toString方法以及Item的构造方法复杂度很高；再其他就是ExprProcess处理类复杂度很高。

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

第三次做业

程序结构大体如图：

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

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

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

方法复杂度如图：

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

1. ExprProcess静态方法类，因为依旧是与第二次做业类同的组合方式，写出了这么个静态方法类，形成了单一方法巨大的复杂度，应该按照我在我开头引用的个人博客连接里的Parser的写做方法，把复杂度分散到不一样Parser接口实现中，可是这基本上是我第三次做业写完了才学到的方法，因此没有运用；
2. AtomFactory类的两个静态方法，这是我为了集约式根据枚举类型建立子类而编写的，复杂度高情有可原；
3. PlusAtom和MultiAtom的Merge方法，由于处在合并同类项层次，故而要处理的类不少，因此复杂度极高，是属于能够拆分的；
4. 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。

(4)Applying Creational Pattern

前两次做业因为类的数目在设计上就比较稀少，第一次3个，第二次6个，在编程上并无学会或者是意识到要运用什么设计模式；

可是第三次做业达到了空前的突破，达到了17个类，这时我也意识到了工厂方法，能够更加灵活地建立对象，并私有化构造器，若是如今让我设计，第三次做业的表达式树部分的类，我必定会采用统必定义接口的方式，实现接口的类都添加工厂方法，以此来梳理结构，减轻父类甚至去除父类。