第一次作业设计思路
- 类结构
建立两个类：Polymonial与Exec。
Exec类中有main方法，负责创建Polymonial类的实例并控制Ploymonial进行表达式的读入、求导与打印。
Polymonial类中包含内部类Term，每个Term类的实例代表表达式的一个项，其中包含coefficient与index成员，分别代表项的系数和指数。
Polymonial中含有Term类的ArrayList容器pol，代表整个表达式。表达式的读入由方法read进行，其中应用正则表达式进行合法性的判断，利用group方法提取出表达式中每一项的系数和指数，对每一项新建一个Term类的实例并放入pol中。
表达式的求导由方法derivate进行，该方法对pol中每个Term类进行forEach遍历并进行求导。
表达式的输出由方法print进行。print方法先对pol按照index进行排序，然后用forEach对每个Term类进行遍历输出。
- 设计缺陷与Bug
第一次作业主要的设计缺陷是没有对Term内部类编写求导与打印方法，而是将其交给Polymonial类进行。
Bug包括在正则表达式的设计过程中没有考虑到^与后面的指数之间可能包括空格的情况，从而产生WRONG FORMAT的误判。
另一个小的设计缺陷是输出的时候没有先输出正系数的项，导致有的数据会比最短输出多一位，从而性能分没有拿满。
- UML类图
- 度量
第二次作业设计思路
- 类结构
建立三个类：Exec、Function、Term。
Exec中有main方法，负责创建Function类并控制Function进行表达式的读入、求导与打印。
Term中有coefficient、xxIndex、sinIndex、cosIndex成员，分别代表项的系数和x、sin(x)、cos(x)的指数。Term类的derivate方法对当前项进行求导，返回一个Term类型的ArrayList；print方法对当前项进行输出。
Function中有Term类型的ArrayList成员，代表整个表达式，read方法负责读入，match方法判断输入是否合法，以及对输入进行识别，derivate方法调用每个Term的求导方法，并把结果进行合并，print方法调用每个Term方法的输出方法。
- 设计缺陷与Bug
本次我的实现中在Term的print方法进行优化时出现了Bug，导致单独的1项不会被输出，从而导致输出错误。在代码架构方面应该比较合理。
- UML类图
- 度量
第三次作业设计思路
- 类结构
第三次作业较为复杂，涉及到对上下文无关文法的识别以及表达式的递归求导，设计的类比较多，因此设计了一个Derivator接口，所有能求导的项与运算符都实现Derivator接口，从而实现多态的设计。
在基本架构上沿用了第二次作业的架构，即Exec类负责调控，Expression类负责表达式的求导和输出，新增加了一个InputAnalyser类，负责递归地判断及解析输入。由于含括号的表达式不属于正则文法，无法仅通过正则表达式进行解析，因此设计了递归解析的termAnalysis方法。在该方法处理并确认合法后，再将处理的结果传递给Expression的实例。
Expression方法包含Add、Const、Cos、Exp、Mult、Sin方法，由他们组成表达式树，求导时按照求导法则递归求导。
- 设计缺陷与Bug
本次设计中出现了一个比较大的设计缺陷，即单独设计了Add与Mult类，将整个表达式由若干个项加在一起变成了两个表达式加在一起，这种根据文法设计出的架构导致在输出的时候无法很好地合并相同项，不过由于本次测试在性能分方面比较水，因此性能分上并没有低很多。
在输入合法性判断的时候出现了一个Bug，由于正则表达式书写错误，在处理类似sin(sin(x)^3)的输入时会响应WRONG FORMAT。
- UML类图
- 度量
设计模式总结
这三次作业每一次都刷新了我对oo这门课程的理解。
第一次作业由于题目较为简单，因此对设计模式要求并不高，主要内容还是放在对表达式的合法性判断与输入处理上。
第二次的题目与第一次相比其实并没有多大的提升，单个项的参数由两个变成了四个，求导的结果由一个项变成了三个项，因此设计模式和第一次作业也基本没有什么区别。
第三次的题目就比较高级了，由于支持了表达式的嵌套，因此对于设计模式突然有了一定的要求，比如使用借口就可以很好地达到一个多态化的设计。当然第三次作业我主要还是学到了很多文法相关的知识，包括正则文法、上下文无关文法以及它们的识别过程，这无疑让我受益匪浅。
三次作业的互测环节也加深了我对每个程序写出来必定有Bug这一点的认识程度，同时也加强了我寻找Bug的能力。所以总的来说这三次oo作业还是比较有收获的吧。