2019 OO第一单元总结(表达式求导)
一. 基于度量的程序结构分析
1. 第一次作业
这次作业是我上手的第一个java程序，使用了4个类来实现功能。多项式采用两个arraylist来存，系数和幂指数一一对应。
1 private arraylist<biginteger> coefs; 2 private arraylist<biginteger> degrees;
四个类分别为
- poly类，代表表达式；
- polydiff类，代表求导运算；
- polyparse类，封装了格式检查，encoding（输入的多项式转为内部存储形式），优化，decoing（内部存储形式转为输出的多项式）方法；
- polydifftest类，入口类
整个程序既有面向对象的味道(封装)，但不那么纯，也有面向过程的写法。
类图如下：
类复杂度分析如下：
优缺点分析：
这里polyparse类的代码尤其多，在整个设计中，polyparse类是主类，完成了大多数功能，其他类是辅助类。这样的写法犯了面向对象的一个大忌：类失衡。究其原因，还是受到了面向过程思想的影响。其次可以直接用hashmap而不是arraylist来存表达式。
对于第二次作业而言，本次作业的扩展性还行，给出了整个求导的框架。
2. 第二次作业
本次作业最重要的变化是加入了三角函数。为了使用上次作业的架构，我只改变了表达式的存储形式。对于求导，采用的方式还是和上次作业一样，直接带公式。关键是项的表示形式。
以 x, sin(x), cos(x) 做为基函数，对于任何项 kxasin(x)bcos(x)c 都可以表示为 (k,(a,b,c))(k,(a,b,c)),
采用复合函数求导公式 (uvw)' = (uvw)′=u′vw+uv′w+uvw′ 得到的结果为3个项，具体形式可以拿公式直接得出来。
类图如下：
类复杂度分析如下：
优缺点分析：
这里优化的类里面的代码尤其多，为了保证每个方法的行数小于限制行数，只能强行将优化函数拆成3个不同功能的优化，但里面有很多冗余的代码。
对于第三次作业而言，本次作业不具任何的扩展性，这种求导的框架走到了尽头。
3. 第三次作业
本次作业加入了嵌套因子和表达式因子，由于前两次作业不能扩展以及之前写过编译器的经验，这一次我是推倒重来，从头开始写了小型编译器。
求导过程可看作是一个翻译过程：源语言：原表达式，目标语言：求导后的表达式。指导书上对于item的要求看起来复杂，但拆成一个个小单元后，很容易就能写出item的文法，之后采用递归下降分析法，一次扫描，同时完成了格式检查和求导的工作。
我d得这次作业最精彩的是我的求导都是形式求导，实质是字符串的拼接。
比如a=b*c 有了b和c本身以及b和c求导后的表达式b',c'的string形式，套公式(字符串拼接)就可以得到c'=b'c+bc'的string形式。整个过程非常简单。不论是乘法，加法还是嵌套，都可以用这种方式解决。
类图如下：
类复杂度分析如下：
优缺点分析：
采用了编译器的经典架构：expr,item,factor,lexer,symbol,pow,sin,cos类的划分明确，职责清晰。类复杂度分析图中标红的地方是由于使用了大量的if,else或者switch，但这个也必须用，不知道有没有更好的对于if,else的改写方法。
还是只用了封装，继承，多态，接口一个都没用上。注意之后的重构部分会给出一些修改方法。
二. bug分析
第一次作业：
较为简单，暂无bug发现
第二次作业：
这次作业的bug出在了优化部分，可谓是画蛇添足。
测试用例：3*x + sin(x)^5*cos(x) - sin (x)^3*cos(x) - sin(x)*cos(x)^5 + sin(x)*cos(x)^3
错误输出：7*sin(x)^2*cos(x)^2-4+7*cos(x)^2
特征：向map中添加元素的时候，没有先调用get()来得到原来的key之后再累加上去，而是直接调用put()方法覆盖了原来的key。导致程序中如果有一个以上sinx^2+cosx^2=1或1-sinx^2=cosx^2或1-cosx^2=sinx^2的合并时出现错误。
问题所在的类和方法：optimization类的opt1，optimization1，optimization2方法。
bug位置与设计结构之间的相关性：优化类的结构一开始每个方法写的很长，超出了最大行数的限制，之后强行拆成了几个方法，导致方法的功能有些混乱，在测试时没有找到bug。
分类树角度分析程序在设计上的问题：分类树是一种使用树状结构来构造测试用例的方法，避免了测试用例的冗余。我在本次作业中构建的测试用例只针对了正确性，对于能够优化的用例，我只构造了几个，没有完全覆盖优化的函数。
第三次作业：
暂无bug发现，为了防止错误出现，没有做过多优化。
三. 测试方法
虽然我们没有互测，但自动测试可以显著提高测试效率，很有必要实现对拍程序。
1. 构建测试用例
对于第三次作业，情况较为复杂，采用随机生成大量用例的方法易生成大量类似测试用例，不能保证全覆盖。我依照指导书精心设计了30多个用例，保证了测试的全覆盖。
2. 测试方法
稍微修改java程序的main方法，使其从文件读表达式，将结果输出到文件。使用python的sympy库编写对拍程序，符号求导，代入随机数运算后比对，实现了正确格式用例的测试。对于wrong format的测试，直接看java程序是否输出wf。
四. applying creational pattern
第三次作业依旧没有使用继承和接口，但每个类的形式都是一样的。
1 private string fun = "";
2 private string difffun = "";
3
4 string getfun() {
5 return fun;
6 }
7
8 string getdiff() {
9 return difffun;
10 }
11
12 void analyse() {
13 ......
14 }
重构：
新建一个父类对象expression包含fun和difffun变量成员，getfun()和getdiff()函数成员。由于每个子类的analyse()行为不一样，无法使用父类的getfun()和getdiff()完成功能，因此直接将analyse定义为一个接口。每一个子类需要继承父类expression并且实现接口analyse。
我的设计思路中也体现出factory pattern的思想。因为语法分析的结果实质是构建了一个语法树，每一个父节点都会创建两个子节点，并且调用子节点的getfun()和getdiff()函数，整个过程是一个递归过程，最终从树的根节点上拿到结果。