【面向对象】第一单元总结——表达式求导
基于度量的程序结构分析
第一次作业
类图
代码规模
代码度量
“ ev(G)基本复杂度是用来衡量程序非结构化程度的，非结构成分降低了程序的质量，增加了代码的维护难度，使程序难于理解。因此，基本复杂度高意味着非结构化程度高，难以模块化和维护。实际上，消除了一个错误有时会引起其他的错误。
Iv(G)模块设计复杂度是用来衡量模块判定结构，即模块和其他模块的调用关系。软件模块设计复杂度高意味模块耦合度高，这将导致模块难于隔离、维护和复用。模块设计复杂度是从模块流程图中移去那些不包含调用子模块的判定和循环结构后得出的圈复杂度，因此模块设计复杂度不能大于圈复杂度，通常是远小于圈复杂度。
v(G)是用来衡量一个模块判定结构的复杂程度，数量上表现为独立路径的条数，即合理的预防错误所需测试的最少路径条数，圈复杂度大说明程序代码可能质量低且难于测试和维护，经验表明，程序的可能错误和高的圈复杂度有着很大关系。”
——引用自《OO课程中IDEA相关插件的使用》
第二次作业
类图
代码规模
代码度量
第三次作业
类图
代码规模
代码度量
优点和缺点自我评价
我的优点是程序结构构架地比较清晰，方法功能独立，代码中注释写得较为明确；缺点是喜欢用较长的正则表达式，没有对最后的输出结果进行优化。
分析自己程序的Bug
自己的程序可以较好地识别正确的，和有明显错误的输入内容，并正确地计算出结果。但遗憾的是对于一些非直观的，相对于真实计算情境下非正常思路的输入内容的识别力较差，比如+++2019这种类型的输入，我在设计上没有考虑到对这些情况的包容，或者说，对于这类输入的分析、解析没有较好的设计思路。
分析他人程序的Bug的策略
在本单元的程序设计中，我主要采用了以下两种方法去测试他人的程序：
· 根据自己在编程过程中的思考和遇到的问题来对他人的程序进行测试。由于每个人的解题思路和程序构建思路是不同的，所以按照自己的程序逻辑流程可以解决的输入内容，不一定在他人的程序中也可以顺利解决。
· 我假定在进行下一阶段的测试时，他所基于的之前的阶段的代码都已经经过充分测试，所有的回归测试都能通过，也就是说，程序中最禁受不住测试的地方是他根据新要求，进行改编的新代码。那么我会针对本次作业中的新要求的各种表现形式对他人的程序进行测试。
对象创建模式的应用
在本单元的三次作业中，我主要采用了工厂模式的对象创建方法。对Expression/Term/Factor的创建方法都是通过传入字符串，返回一个相应的对象去完成，其中FactorX/.Sin/.Cos/.Const继承于Factor父类。在方法调用上，他们对外的接口都基本只有.derivation() & .toString() 方法，分别返回他们加上括号的的导函数（String）和原始内容（String）。
