面向对象设计与构造第一单元博客作业

第一次作业总结

类图

总类图

作为第一次作业，总体设计上有不少缺陷，但因为作业复杂度还不算高，因此看着还不是很乱，但其实已经出现接口/类的迷惑定义了，这也部分程度上导致了第二次的重构。

关键部分类图

第一部分是字符串输入后的解析。这部分因为有官方training，所以构造起来还比较简单，架构也基本相仿。

第二部分则是存储字符串的类。这部分我是在training发布前就先自己构建了的，后来也就头铁的这么做了。和官方示例略有不同，并没有把多项式和常数、幂函数当作纯粹的因子，同时也作为了项来处理。这一不同导致了第二周还没开始就准备起了重构。

核心类设计分析

字符串解析类

主要由两个类构成，Lexer和Parse。

Lexer：对字符串进行最直接的处理，留有一个方法用于传递当前指向的符号/数字/变量。

Parse：一个工厂，控制Lexer向后解析的同时根据Lexer的返回值组合生成因子、项以及多项式。

优点：考虑到后续可能出现的括号嵌套等问题，所以直接采用正则表达式来解析并非一个很好的选择，因此递归下降法对字符串进行解析更具有普适性。

缺点：本次设计过程中，出于取巧把化简运算直接放在Parse中进行了。虽然结果上不会有区别，但将两种操作（解析并存储，计算）揉在一起不是一个很好的设计思路，毕竟Parse的职责是解析并生成字符串而不是去进行运算化简。

字符串存储类

根据指导书的定义，因子实际分成了三类：表达式、常数、变量x。其中，表达式用多项式来表示，常数和变量x则合并在一起用“单项式”来表示，即a*x**b（b=0时即为常数）。

因子接口Factor：包含了因子通用的方法，如乘法、设置乘方。

项接口Term：此处设计并不好，对于扩展三角项较为困难。第一次这么设计的原因在于开始对多项式与单项式都定义了加法和乘法运算，而加法运算是项所独有的，所以认为这两种因子也同时具有了项的特性。但实际上项应该是独立于这两种因子的，这点在第二次添加三角函数后会体现出来。

多项式Polynomial：内含单项式的列表，可以和其他因子（多项式、单项式）做乘法，和其他项做加法（合并同类项），以及实现自身的乘方运算来去除乘方的括号。

单项式Monomial：包含一个系数coefficient和变量x的幂次index，可以做多项式除了乘方以外的运算。

优点：对两个实际的运算存储单元定义了各自的运算规则，并返回统一的接口类型，比较符合内聚的思想，外界调用的时候不必再考虑实际的运算过程。因子=多项式/单项式的结构也没有问题。

缺点：Term作为接口的设计是违背与实际层次结构的。表达式-项-因子的层次结构比较清晰且符合实际，而把本来是因子的多项式/单项式看作项容易导致结构上的混乱，同时直接把单项式看作一个基元存储在表达式中也不合理，打破了层级之间的递进关系，极大的限制了后续对于项的定义的延申。

基于度量的结构分析

代码规模分析

整体结构比较简洁，没有过于臃肿的类出现

类复杂度分析

没有十分复杂的类出现，各个类之间较为平均。

方法复杂度分析

这里只截取了复杂度从高到低排列后复杂度较高的方法。

lexer.next()因为要解析各种不同的字符所以if判断较多，v(G)复杂度相对较高。

Monomial.toString()方法因为要综合考虑系数和x的指数，判断也较多。

优化分析

所有所做优化如下：

乘法合并：

常数和常数相乘，带x的项相乘为指数相加

加法合并：

同幂次的项可以相加，如2*x+3*x，不同幂次的项合并为一个新的多项式，如2*x+3*x**2。

输出优化

系数为0的不进行输出，如0*x返回空字符串，除非最后的输出为0

指数为1的不输出指数项，如x**1输出x

平方输出由x**2输出x*x

系数为1或-1时不输出系数，如1*x输出x，-1*x**2输出-x**2

未做优化

正项提前，如-1+x输出为x-1

bug与测试

测试数据构造

用c++写了一个测试样例生成器，生成逻辑根据指导书规则而定，如下：

根据规则构造了一些常量，形成常量池

最外层为一个多项式，包含了随机个数的项，每个项通过createTerm()生成

每个createTerm()方法可以调用上面的四个方法生成包含的因子，为了避免嵌套设置了一个全局开关保证createSubExp()中调用的createTerm()不会再调用createSubExp()。

bug分析

第一次作业较为简单，全屋无人被发现bug。

第二次作业

类图

总类图

解析部分类图

解析部分的架构没有发生改变，仅在内容上添加了对于新增的三角函数、求和函数、自定义函数的解析处理方法。

存储运算部分类图

此部分改动较大，不仅根据新增要求添加了许多类，还进行了部分重构。主要重构了Term，严格遵循表达式-项-因子的层次结构进行构建，也因此对原来类的耦合关系进行了调整。

核心类设计分析

字符串解析

对于新增的自定义函数和求和函数，沿用了因子表示法而不是字符串替换法。由于函数声明与表达式处理时的解析区别，分成了两个类。

FuncParser：用于解析函数声明，存储函数名、形参列表、函数表达式的对应关系。

ExprParser：用于解析待处理表达式，解析函数时会根据FuncParser的存储结果生成形参与实参、表达式相对应的函数。

存储计算

根据重构后的层次结构，形成了如下的类。

Polynomial：只存储包含的项Term，可以做的运算只有两个项之间的合并（merge()方法）以及自身的乘方运算(pow()方法)。

Term：包含两个互斥的部分。项在化简完成前，factors存储在解析时的所有因子。项内化简完成后，用monomial和triangles存储一个项的全部特征：系数、（x的）指数、所有三角函数。只可以进行项和因子/项的乘法运算。

Factor：在解析时的最底层形式。化简时，函数因子中的Variable会被替换为多项式因子，然后将函数因子以多项式的形式返回进行运算。最后存在的因子只会有Monomial和Triangle。

Optimizer：在所有基础化简（加法、乘法的合并同类项）完成后进行三角优化。