oo第一单元总结

第一次做业

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

类图：

设计了两个类，如今看来这个设计很不合理，把过多的功能揉在了一个类内里，不利于扩展和修改。两个类分别为computepoly类和poly类，computepoly类负责提取出每个项的字符串并传入poly类，以及负责项与项之间的计算和结果的输出；Poly类则负责提取和存储，每一项的系数和指数，同时接受computepoly类的传入和调用。
度量分析：

Metrics图中显示out方法的McCabe Cyclomatic Complexity即圈复杂度过大。Out方法是负责结果输出的方法，由于在里面使用太多的if-else语句，使得圈复杂度过大。

(2)分析本身程序的bug

第一次做业有三个bug。第一个bug为，当输入全为空白字符时，没有报错。第二个bug为，看成为指数的带符号数字中间出现空白字符时，没有报错。第三个bug为，系数和指数的数据类型设计错误，当系数超过long和指数超过int时，程序直接出错。前两个bug均为未考虑全面格式错误，后一个bug则是设计上的考虑欠缺。

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

发现了别人一个bug。经过查看别人程序的正则匹配，发现其并未对除x之外的字母出现报错。

第二次做业

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

类图：

设计了三个类，在扩展上一次的基础上把输出单独写成了一个类，但设计依然很不合理，computepoly类依然负责的太多，能够把对格式的检查等写在别的类里。三个类分别为computepoly类，poly类和hand类，computepoly类负责格式的检查，提取出每个项的字符串并传入poly类，以及负责项与项之间的计算；Poly类则负责提取和存储，每一项的系数和指数，同时接受computepoly类的传入和调用；hand类负责结果的输出。
度量分析：

Metrics图中显示，依然是执行输出的方法的圈复杂度过大。Printo方法是负责结果输出的方法，由于在里面使用太多的if-else语句，使得圈复杂度过大。

(2)分析本身程序的bug

第二次做业有一个bug。Bug为，当一个项以*开头时没有报错。这个bug是设计思路上的不严谨。

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

发现了别人一个bug。一样是经过查看别人程序的正则匹配，发现其没有对s i n(x)进行报错处理。

第三次做业

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

类图：

设计了五个类。分别为computepoly类，expre类，term类，factor类，pol类。computepoly类负责格式的检查以及对总体的调用。Expre类，负责表达式级别的提取和求导。Term类，负责项级别的提取和求导。Factor类，负责因子级别的提取和求导。Poly类负责系数和指数的提取，以及部分因子的获得。computepoly类调用expre类，expre类调用term类，term类调用factor类，factor类视状况调用factor类或expre类，即依此递归。
度量分析：

Metrics图中显示，因子类内里，对因子求导的factordao方法的圈复杂度过大，以及对因子进行识别的factorcompute方法的嵌套深度过深。factordao方法由于把多种状况的求导揉在了一块儿，因此其圈复杂度过大。factorcompute方法，则是嵌套的判断太多，使得嵌套深度过深。

(2)分析本身程序的bug

第三次做业有两个bug。第一个bug为，当一个项以*结尾时程序出错。第二个bug为，当项的第一个因子为-1并省略为-时，-没有被记录。第一个bug是设计上的不严谨。第二个则是由于对判断条件的设置错误。

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

发现了别人一个bug。经过构造不断嵌套且为不一样状况的表达式。

(4)Applying Creational Pattern

三次做业均采用建立型模式（Creational Pattern）。

总结

在第三次做业中，尝试使用接口，但由于设计和理解方面的问题，没有实现。有一个好的构思和设计，在具体实现过程当中，会起到事半功倍的效果。