oo第一单元总结

一、基于度量的程序结构分析

1.第一次作业

1.1 UML类图

1.2 代码复杂度

 

2.第二次作业

2.1 UML类图

2.2 代码复杂度

3.第三次作业

3.1 UML类图

3.2 代码复杂度

4.设计思路综述

　　三次作业均遵循了多项式类调用输入句柄获得输入，分析输入来生成项类，项类再进行分析获得因子类。最终的求导是基于因子来进行的。在具体分析的实现上，前两次作业是采用了纯粹的正则表达式的方法。第三次作业因为我在构建正则表达式上出了问题，所以最终采用的是一个比较复杂的自顶向下的递归分析法。也正因为第三次作业分析的中间结果比较复杂，所以在化简，合并上出现了比较大的问题。

　　总体来说，前面两次作业设计的相对较好。从最终互测阶段的表现上看，前两次作业无论是在BUG数量上还是在修复BUG的困难程度上都要明显好过第三次作业，这与较低的代码复杂度会引入更少的错误，修复起来也更加容易的经验之谈是相吻合的。

二、分析自己程序的bug

　　第一次作业未检测出BUG。

　　第二次作业的BUG主要出现在幂函数的系数的判定上。指导书要求幂函数的指数的绝对值不超过10000，我对指数的判定是放在幂函数因子的构造函数中判断的。但是当我求导得到新的幂函数时也直接调用了幂函数的构造方法。但是在求导生成新的幂函数时并不限制幂函数的指数。即x**-10000是合法的，求导得到-10000*x**-10001也应该是合法的，此处就不应该进行指数的判定了。

　　第三次作业的BUG相对较多。因为中间结果比较复杂的原因，在重写toString方法时出现了比较多考虑不周的情况。而且由于算法实现上的问题，在多层嵌套时会出现运行时间过长的问题。

三、分析自己发现别人程序bug所采用的策略

　　互测阶段我做的比较随意，并没有去专门思考可能在哪些问题上出错。用来测试的样例也都是我在调试我自己的程序中所用到的。大概还停留在手动构造测试样例的阶段。对边界数据，特殊情况等考虑的不是特别全面。

四、应用对象创建模式来重构

　　三次作业的架构差别并不大，但是第三次作业在分析思路上做了变化，总体上还是遵循多项式-项-因子的层次结构。

五、对比和心得体会

　　最大的心得体会就是一个好的设计可以极大的提升编写代码，查找修复BUG的体验。也就是先构思再下手。一边想一边写，最后的结果就是缝缝补补整出来个过了几天自己都不想看的垃圾。来自至今仍在尝试修复第三次作业的BUG的血泪教训。

　　还有就是抓紧时间，有一些细节上的实现花费的时间超过我的估计，因此为了保证自己有充足的时间来达到自己预期的设计目标，尽早动手是个很好的习惯。