BUAA-OO-Unit1-单元总结

张珺强-22373215 学生 2024-03-22 15:00:19

OO-Unit1-单元总结

1.基于度量的程序结构分析

代码量分析

总行数1093行，源码992行。我会在写出某一功能模块的代码后进行一定的测试，从而在一定程度上减少出现bug的可能，不过我会将一些测试用的代码注释掉。

OO度量

Complexity Metrics 复杂度分析

类复杂度

可以看到，Simplify, Poly, Func等类为低内聚类。
Simplify类的功能是对读入的一行字符串进行化简，去除多余的空白符号、+/-号等，复杂度较高。
Poly类定义了HashMap存储结构下所有的多项式计算方法，复杂度高。
Func类定义了所有的与自定义函数有关的行为，包括读入、化简、代入参数等等。
Expr类定义了表达式的存储结构、打印等功能。
Parser类负责执行递归下降的过程。
值得关注的是，MainClass类的内聚性不尽人意，可能的原因是我在编写代码时还是残留了一定的面向过程编程的思维，在之后的学习中我会更加彻底地贯彻面向对象设计与构造的思想。
另外，可以观察到Expr类和Parser类的WMC较大，即拥有过多的方法，原因是Expr类承担的功能太多，而Parser类是因为我把很多分支的执行过程也抽象成了独立的方法，这是为了满足方法最大行数的限制。

本单元代码的类复杂度较高，需要在下一单元的学习中注意。

方法复杂度

可以看到，我的代码中一些方法不符合高内聚低耦合的要求。
Expr.link()的功能是将一个用HashMap存储的形如a*x^b的单项式转化为字符串，是我的代码的核心功能，所以实现后的复杂度较高。
Expr.getGcd()则是提取一个exp()括号中的表达式的所有项的系数的最大公因数，由于存储方式的原因，该方法的实现较为复杂。
Expr.specialLink()的功能是保证exp()中的表达式的括号层数的正确性，是hw2代码的核心部分。
同时，我注意到某些方法的耦合性较高，考虑到这些方法多是具有综合性功能的模块，所以是可以理解的。`

Expr类中的方法的平均复杂度极高，原因是我的架构中Expr类承担了太多的功能，但在一定程度上简化了思维难度和代码的实现难度。

Dependency Metrics 依赖度分析

类图分析

MainClass类：读入数据，并调用其他类，生成最上层的表达式。
Simplify类：对读入的表达式和初步生成的表达式字符串进行化简，去除多余的部分。
Lexer类：分析字符串，将其转化为curToken字符来逐一识别并处理。
Parser类：递归下降识别表达式的每一部分，并返回Expr类或Term类的实例。
Expr类：定义了所有的表达式的基本形式为(多项式)*exp(多项式)，并用HashMap存储，同时实现了一系列配套的功能，如基于表达式生成字符串，表达式合并，求多项式的最大公因数等等，继承Factor接口。
Term类：定义为项，会被Expr用新定义的表达式加法合并，继承Factor接口。
Poly类：方法类，定义了一系列的计算用的方法，如表达式的加法和乘法等等。
Func类：定义了自定义函数的存储方式和一系列相应的功能，如读入自定义函数，代入参数等等，继承Factor接口。
Variable类：定义了字符串类型的变量的行为，继承Factor接口。
Factor接口：接口，定义了getMonomial()等行为。

优点：

a.较为清晰的定义，将所有的表达式都归为`HashMap<Expr,HashMap<BigInteger,BigInteger>>`的标准形式，降低了构建架构的思维难度，逻辑清晰明了。

b.采用递归下降来解析表达式，有利于迭代开发。

缺点：

a.采用了过多的递归调用，导致某些方法的耦合度过高。

b.对表达式的存储容器，选择了递归定义的方法，导致了在定义‘0’的况时使用了危险的存储方式。

c.在控制exp()中的括号层数时，必须读取分析exp()括号里的下层表达式，通过分析的结果来选择输出方式的分支，不符合面向对象的设计思想，这是代码的最大缺点，也是我最不满的一点。

2.bug分析

在hw2中出现了一次bug，导致未通过弱测（唐完了）：

没有将所有形如(a*x^b+c*x^d)*exp(表达式)中的前一个多项式的括号拆掉。
最大的原因是我没有完全读懂题目，以后一定认真读题。
次要原因是我存储表达式的方式导致了我没有在编写代码时想到拆开这种括号。在主函数的parser.expr()执行后，所有表达式都会以(a*x^b+c*x^d)*exp(表达式)的形式存储，然而我在输出时直接以这种形式输出了表达式，并没有运用乘法分配律拆开括号。所以也可以说，我的架构的缺陷是产生bug的原因之一。

观察到出现bug的方法较为繁琐，验证了“越是复杂，越是错误”的说法，在之后的OO学习中，我会尽力将所有方法的代码变得简洁，不将多个功能杂糅在一个方法中。

hw1的互测中被成功hack了两次，检查后发现bug是处在Poly类中的静态计算方法中

具体来说，问题出在两个多项式相乘的计算方法上。运用乘法分配律，当一个新的乘法结果被模拟加入到作为结果的HashMap中时，如果某个指数对应的系数将会变为0，那么实际上不会执行加入的操作，但实际上还应该进行将原来的key-value映射删除的操作。这导致了bug，下面是一个简单的例子：

Input：
0
(x+1)*(x-1)

Output:
x^2+x-1

显示出现错误，正确的输出应该为x^2-1。+x在遇到-x后本应该被抵消，但实际上留存在了result中。

这个bug出现的主要原因是没有做好单元测试，如果在编写完这个计算多项式乘法的方法后进行充分测试，就能消除这个bug，这警示我在之后的迭代中进行充分的单元测试。

3.互测体验

我的互测体验较为良好，虽然没有hack成功过别人，但也让我在阅读他人代码时了解到了新的创意，也在构造测试数据时想到了没有涉及过的分支情况。

我比较喜欢结合他人的代码结构来设计构造测试用例，比如对时间复杂度较高的架构，我会构造时间复杂度尽可能高的测试数据。然而受制于数据代价，我构造的一些数据虽然可以卡爆他人的程序，但无法提交到互测中。

4.架构的迭代设计

hw1

我在hw1时最初的设想是用ArrayList存储读取到的表达式，但是发现时间复杂度极大，并且难以合并同类项，所以我在思考选择了HashMap<Integer,BigInteger>来存储形如a*x^b+c*x^d表达式，key为指数,value为系数。这样大大提高了程序的运行速度，使得我轻松通过了第一次测试（然后似在互测）。
但是，hw1的架构存在着隐患。

hw2

在hw2中，exp()加入了表达式体系中，我的思维一度卡在如何存储exp()上。然而，当我重新审视我的hw1架构时，我惊喜地发现如果在原来的HashMap<>的外面再套一层HashMap，就可以完美地进行迭代开发，原来的一切方法和容器都可以直接用而无需修改，只需要进行新增内容的开发。同时，新的存储容器HashMap<Expr,HashMap<BigInteger,BigInteger>>使用了递归定义的形式，一定程度下降低了开发难度。
从hw2的开发中，可以看出我最初定下的架构的可迭代性较强，也是一件幸运的事情（然后似在弱测，无效作业闹麻了）。

hw3

hw3的迭代开发是最简单的一次，我仅用了一小时左右就完成了初步编写。我在开始开发hw3之前，认为自己的hw2架构已经可以处理自定义函数的相互引用定义，因此只编写了表达式求导部分相关的代码。
但是在之后的本地测试中我测出了bug，经过重重排查，我发现了hw2中的一行判定代码的写法导致了无法识别自定义函数的相互引用定义，这是我在编写时遗漏的，不过若是我在hw2中就采用更好的判定写法，或许可以减少这种情况的发生。