BUAA OO 第一次作业总结

第一次作业

简介

第一次作业是简单的多项式求导。

UML 图与类结构

其中，各个类的含义如下：

|- MainClass：主类
|- expression (package)：表达式包
    |- Factor (abstract class)：因子类
        |- Constant：常数类
        |- Var：变量类
        |- Term：项类
        |- Expr：表达式类
|- parser (package)：表达式解析包
    |- Parser：语法分析器
    |- Tokenizer：词法分析器
        |- TokenType (enum)：词法单元类型
|- Pair：元组

最重要的抽象类 Factor 共三个方法：

abstract Factor derivate()：求导
abstract String display()：打印当前因子
abstract Factor simplify()：化简因子

架构分析

我的代码分为了两个 package，其中 parser 用于解析输入，expression 用于处理表达式。除此之外，还有一个辅助的工具包 Pair。这个架构还是比较直观的，分类方法是“因子类型”或者说是“求导法则”。

设计理念

我首先用递归下降法解析输入，然后对得到的表达式进行第一次化简。之所以这里要插入一次求导，是因为求导的时候表达式可能会急剧膨胀，先化简有利于减小后面的负担。接着对化简结果进行求导，并且再次对结果进行化简，最后输出结果。

度量分析

可以看到，我的代码复杂度总体还是可以的。

唯一的问题在于 Parser 的平均循环复杂度较高，主要问题在于递归下降的过程中会有大量的路径依赖，或许可以通过为方法创建一个 map 解决问题，但是在这里感觉有点杀鸡用牛刀，故没有更改。

方法圈复杂度分析

方法	CogC	ev(G)	iv(G)	v(G)
MainClass.main(String[])	0.0	1.0	1.0	1.0
expression.Constant.Constant(BigInteger)	0.0	1.0	1.0	1.0
expression.Constant.derivative()	0.0	1.0	1.0	1.0
expression.Constant.display()	0.0	1.0	1.0	1.0
expression.Constant.getValue()	0.0	1.0	1.0	1.0
expression.Constant.hashCode()	0.0	1.0	1.0	1.0
expression.Constant.simplify()	0.0	1.0	1.0	1.0
expression.Expr.Expr(ArrayList<Pair<Term, BigInteger>>)	0.0	1.0	1.0	1.0
expression.Expr.consTerm(Term,BigInteger)	0.0	1.0	1.0	1.0
expression.Expr.derivative()	0.0	1.0	1.0	1.0
expression.Expr.getTerms()	0.0	1.0	1.0	1.0
expression.Expr.hashCode()	0.0	1.0	1.0	1.0
expression.Term.Term(ArrayList<Pair<Factor, BigInteger>>)	0.0	1.0	1.0	1.0
expression.Term.Term(BigInteger,HashMap<Factor, BigInteger>)	0.0	1.0	1.0	1.0
expression.Term.consPower(Factor,BigInteger)	0.0	1.0	1.0	1.0
expression.Term.getCoe()	0.0	1.0	1.0	1.0
expression.Term.getFactors()	0.0	1.0	1.0	1.0
expression.Term.hashCode()	0.0	1.0	1.0	1.0
expression.Var.derivative()	0.0	1.0	1.0	1.0
expression.Var.display()	0.0	1.0	1.0	1.0
expression.Var.equals(Object)	0.0	1.0	1.0	1.0
expression.Var.hashCode()	0.0	1.0	1.0	1.0
expression.Var.simplify()	0.0	1.0	1.0	1.0
pair.Pair.Pair(A,B)	0.0	1.0	1.0	1.0
pair.Pair.Pair(Entry<A, B>)	0.0	1.0	1.0	1.0
pair.Pair.getFirst()	0.0	1.0	1.0	1.0
pair.Pair.getSecond()	0.0	1.0	1.0	1.0
pair.Pair.hashCode()	0.0	1.0	1.0	1.0
parser.Parser.parse(String)	0.0	1.0	1.0	1.0
parser.Tokenizer.Tokenizer(String)	0.0	1.0	1.0	1.0
parser.Tokenizer.addToken(String,TokenType)	0.0	1.0	1.0	1.0
parser.Tokenizer.consumeToken()	0.0	1.0	1.0	1.0
parser.Tokenizer.hasToken()	0.0	1.0	1.0	1.0
parser.Tokenizer.isDeli(char)	0.0	1.0	1.0	1.0
parser.Tokenizer.isWhite(char)	0.0	1.0	1.0	1.0
expression.Term.derivative()	1.0	1.0	2.0	2.0
parser.Parser.consumeFactor()	2.0	2.0	2.0	2.0
parser.Parser.consumePowerPair()	2.0	2.0	2.0	2.0
parser.Tokenizer.getToken()	1.0	1.0	2.0	2.0
parser.Tokenizer.getTokenType()	1.0	1.0	2.0	2.0
expression.Constant.equals(Object)	2.0	3.0	1.0	3.0
expression.Expr.equals(Object)	2.0	3.0	1.0	3.0
expression.Expr.packTerm(Factor)	3.0	3.0	3.0	3.0
expression.Term.display()	4.0	1.0	2.0	3.0
expression.Term.equals(Object)	2.0	3.0	1.0	3.0
expression.Expr.simplify()	4.0	4.0	3.0	4.0
expression.Term.simplifyEntry(Entry<Factor, BigInteger>)	3.0	3.0	4.0	4.0
pair.Pair.equals(Object)	3.0	3.0	2.0	4.0
parser.Parser.consumeNumber()	3.0	1.0	4.0	4.0
parser.Tokenizer.getDeli(char)	1.0	4.0	1.0	4.0
parser.Parser.consumeTermPair()	4.0	1.0	5.0	5.0
expression.Term.simplify()	6.0	5.0	4.0	6.0
parser.Parser.consumeExpr()	7.0	4.0	6.0	6.0
expression.Expr.display()	9.0	2.0	4.0	7.0
parser.Tokenizer.getTokens(String)	17.0	3.0	10.0	12.0
Total	77.0	85.0	96.0	116.0
Average	1.4	1.5454545454545454	1.7454545454545454	2.109090909090909

可以发现，大部分方法圈复杂度较低，在可以接受的范围内。

出现问题的几个主要方法为 simplify 和 parse，考虑下一次改进。

性能分策略

本次作业比较简单，如果想要获得更多的性能分，可以从以下几个角度分析：

x**2 变为 x*x
正号提前，即-1+x 变为 x-1
合并同类项

类型拆包（性能分重点）

我自己造出来的名词，需要配合合并同类项使用。

在化简的过程中可能会遇到类型过度包装的问题。比如一个简单的数字，parse 的时候可能变成了一个 Expr(Term(Power(Constant(2), 1), 1))，即 \(1 * 2^1\)。显然这样是不利于化简的，因为 equals 和 hashCode() 会判断这样的式子和 \(2\) 不等价。因此要进行“拆包”。

实际上类型拆包并没有化简什么，只是减少了类型的封装层次。

BUG 分析

第一次强测被 Hack 惨了 QAQ。

BUG	所在类	所在方法	原因
对于 `2**2` 的因子没拆开	`Term`	`display()`	没看清题意

得益于 Stream 的高度抽象性，修复 BUG 以后，代码行数增加了两行，圈复杂度未增加。

Hack 策略

我使用的 Hack 策略是随机数据 + 定点爆破。其中定点爆破又包括自己想的易错样例和阅读同学代码分析出的 BUG。

由于第一单元的代码比较简单，所以随机数据的效果比较好。并且阅读代码比较快，因此 Hack 成绩比较理想。

重构感想

第一次作业我经过了大量的重构，主要是为了后面的作业进行铺垫。（虽然第二次又重构了）

我认为作业的难点在于“合并同类项”，并且为此想了很久，终于想出了一个合理的架构方法：在 Expr 和 Term 中，我用 HashSet 来存储儿子，而不用 List，因为 List 在计算哈希值时会考虑到元素的相对顺序问题，而 Set 则无关顺序，只要成员相同可以。为了使用 HashSet，我为每一个类定义 hashCode 和 equals 方法。这个方法直接由 IDEA 生成即可。

虽然花费了大量时间，但是最后重构出来的架构我认为是理想的，在可扩展性和性能优化上比较优越。

心得体会与经验总结

在本单元，我学习到了许多技巧和经验，包括 Java 的使用、递归下降等。

除此之外，我还学到了重构的方法和策略。例如如果是小规模的重构，则逐步替换自己的方法，每次替换用一定的单元测试数据辅助（不会 JUnit，所以是手动测试（悲）），保证重构后的正确性。

第二次作业

简介

这次加入了简单三角函数和括号嵌套。

UML 类图

|- MainClass：主类
|- expression (package)：表达式包
    |- Factor (abstract class)：因子类
        |- Constant：常数类
        |- Var：变量类
        |- Sin：三角函数类 Sin
        |- Cos：三角函数类 Cos
        |- Term：项类
        |- Power：乘方类
        |- Expr：表达式类
|- parser (package)：表达式解析包
    |- Parser：语法分析器
    |- Tokenizer：词法分析器
        |- TokenType (enum)：词法单元类型

得益于第一次架构设计的合理性，本次在架构上没有大的变更，仅仅是增加了两个三角函数类。

并且考虑到 Pair 类型虽然方便，但是在语义表达上不明晰，我替换掉了它，并且换成了 Power 类。