OO前三次作业总结

OO第一单元的三次作业主要是完成对表达式的求导，表达式包含简单的幂函数、正弦函数、三角函数以及它们的组合形式。三次作业难度递增，对面向对象思想的要求逐渐提高，优化难度也逐渐增大。下面是我写完这三次作业的一些感受。

1.程序结构分析

（1）第一次作业：比较简单，但我并没有做到面向对象编程，而是面向过程编程，将整个操作分为读取、标准化、分裂为项、求导、合并五个步骤，把操作的几个重要方法分别在了几个不同的java文件，看似面向对象，实则面向过程，也因此，导致了我第二次作业的彻底重构。

（2）第二次作业：第二次作业在第一次作业的基础上增加了简单的正弦函数和余弦函数，但括号内的因子只能是x，也就是说不会存在复合函数求导。对于第二次作业，我主要有以下几个类：

　　主函数类：负责调用其他类包装的方法，完成需求。

　　多项式类：对输入的多项式进行合法性检测，然后对合法的多项式进行标准化，化成多个常数项*幂函数*sin函数*cos函数相加的形式，特殊的化为1*x^0*sin(x)^0*cos(x)^0的形式，然后在分裂为单项式，调用单项式类进行求导，最后对求导结果进行合并、简化。

　　单项式类：通过调用常数项类、幂函数类、正弦函数类与余弦函数类完成常数项*幂函数*sin函数*cos函数形式的单项式的求导。

　　常数项类：完成常数项的求导，返回原值（a*x的导数为a，整个单项式为常数项也无妨，因为幂函数、正弦函数、余弦函数求导均为0）。求导后为三项相加的形式。

　　幂函数类：完成对幂函数的求导

　　正弦函数类：完成正弦函数的求导。

　　余弦函数类：完成余弦函数的求导。

本次作业初步有了面向对象的影子，但过于臃肿，层次不分明。

（3）第三次作业，在第二次作业的基础上允许了嵌套因子的存在，即复合函数求导，需要在求导的方法内增加复合函数求导的法则，另外需要抓取嵌套因子，判断是否为基本因子——第二次作业中的简单因子，若是，则求导结束，否则递归进行。本次作业需要注意多层嵌套，很容易在嵌套层数过多的时候产生bug。

2.程序bug分析

（1）正则爆栈：第一次作业正则匹配的时候采取了贪婪模式，从而导致了爆栈，修改十分简单，只需要把贪婪模式改为独占模式即可。

（2）标准化错误：在项标准化时，误将-cos(x)标准化为-sin(x)，从而导致巨大的错误，这也提醒我们测试集一定要完备，不要认为测试点很简单就不去测试。

（3）多个运算符连续出现错误：这是我在第二次作业中测中发现的错误，在第二次作业中，对于三个运算符连续出现是认为合法的，而我直接沿用了第一次作业的想法，导致一开始中测没有通过，这提醒我们在看作业指导书时要用心思考，仔细分析作业指导书的要求，以免产生中测中发现不了的bug。

3.发现bug的策略

（1）第一步，单点测试。首先将八个项目集中在一起，从而可以同时测试八个项目；然后利用自己写程序时的测试集进行检测；再依次阅读八个项目的代码，发现bug，构建测试样例。

（2）第二步，批量测试。利用脚本随机产生多项式去同时测试八个项目。

（3）容易产生bug的点：符号问题、嵌套问题、正则问题，所以在阅读他人代码时，应该特别关注这几个点，从而可以更加容易的发现bug。

4.Applying Creational Pattern

项目的层次不分明，应将表达式依次分解为表达式、项、因子三个层次，因子可将常数项与幂函数归入一类、正弦函数一类、余弦函数一类，如此再利用递归便可更加清晰地实现求导功能。

5.总结与反思

作为面向对象的零基础选手，在第一单元经历了由面向过程编程到面向对象编程的转变，我感觉，要做好面向对象编程，最主要的是要搞清楚对象的属性和方法，而不是为了解决某一个问题而构造特定的方法。我认为，一个好的类是可以被广泛继承的，为特定问题构建的特定类，更多的是面向过程的影子。

程序要面向对象，而程序员是面对代码，好的架构与代码风格，会可以帮助我们在写程序过程中犯更少的错误，所以我们应该在写程序之前构建好架构，三思而后写，而不是鲁莽下手，在写代码过程中训练出好的代码风格，尽量摆脱对checkstyle的依赖。