过去的三周里我们完成了表达式求导的程序设计与构造。表达式求导程序，大致思路是实现一个表达式类，支持表达式的输入、求导运算和输出功能。可能的话，还可以增加表达式的化简方法，从而得到更高质量的输出结果。总的来说，输入的处理是最为繁琐，也最容易出错的；而只要表达式类的结构设计合理，求导运算和输出都不会构成太多障碍。
一.程序结构分析
1.1第一次作业
第一次作业我在Main类中写了表达式输入的部分，因此Main类非常臃肿。尤其是对于x的指数部分的处理，判断分支写的很繁琐。这个在后面的两次作业中做了改进。
如上面UML类图所示，表达式由一系列的项组成，项中包含系数和指数。Main类中实例化一个表达式对象，完成输入处理，并调用表达式类的求导方法和输出方法。表达式的求导和输出都是通过调用项的求导和输出来实现的。
1.2第二次作业
可以看到，与第一次作业相比，Main类被很好地简化了，输入的功能放在了表达式的三个类中。因子的输入方法，本事涉及复杂的判断处理；项的输出方法，我的判断逻辑写的比较随意。这两处问题在上面都体现出来了。
Main中提供了字符串处理的下标值，并配备了访问方法和修改方法。表达式类的输入、求导和输出方法都是借助项类的相应方法实现的。项包含四个成员变量，分别是常系数、幂指数、正弦指数和余弦指数。这一次作业的因子其实比较简单，我这里为了后续作业的方便，设计了一个因子类；但这里只做了因子的输入处理，每一个因子在完成输入判断以后就会被并入项中。
1.3第三次作业
可以看到，这次代码中因子类成为了核心，负担很重。与上次作业情况类似，因子的输入和项的输出依然是最大的问题所在，在目前的设计思路下无法简化。
整体的结构与第二次作业非常相近，只是因子类变得更加复杂，并加入了单独的求导方法和输出方法。综观三次作业，主要的改变就是因子类。第一次作业是纯多项式，几乎可以不需要因子的概念；第二次作业可以提出因子的概念，但本身结构简单，可以轻易化简到项中；第三次作业里因子可以包含表达式，不再能轻易化简，而是成为了表达式结构中核心的一环。
二.bug分析
这三次作业我并没有在公测中被查出bug，只是在一些测试点扣了性能分。我第一次作业的nextLine方法没有做异常处理，如果输入为空会导致crash，后两次作业改正了这个问题。还有没有其它bug我就不知道了。
三.bug检测
高工16级没有安排互测，所以我就说下我是如何检测自己程序的bug的。
首先，如我刚才提到，表达式类总共是支持三项功能，我会先单独检查各项功能。先看输入处理能否准确剔除错误格式，提取正确信息，再检查正确的表达式能否顺利输出，最后调用求导方法，检查计算结果是否正确。
各部分检查通过后，再整体做测试。对出现问题的测试数据，再进一步检查，是输入bug还是求导bug等。
我个人的经历来说，前两次作业都在输入这一块出现问题，尤其是第一次作业的时候，感觉很迷茫；而第三次作业的输入处理已经比较熟练了，倒是求导时出现了些疏忽。
四.Applying Creational Pattern
表达式是一个很具体的东西，设计一个功能强大的表达式类，并创建一个表达式对象，是很自然的一种思路。至于求导方法，比起直接写死在表达式类里，如果写成一个接口，感觉结构上更加合理一些。具体的改动不会太大。
五.总结
OO的三次作业做完，我感觉是很有收获的。尤其是当我比较顺利地由第二次作业的代码改出第三次作业的代码时，很深刻地意识到良好的架构在面对需求更改时显现的巨大优势。另外，面向对象的程序，在检查bug方面，相比面向过程的程序要方便一些，但是完备的检查仍然非常困难，我现在也不确定我这三次作业还有多少bug，只能说试着测了我能想到的各种问题，每次交作业的时候其实心里都没什么底。后面的挑战会更加困难，我还需要好好准备。
原文：https://www.cnblogs.com/buaa1623-zyx/p/10608054.html