BUAA OO U1 总结

[陈嘉民-23371149]

OO Unit1 总结

一.前言

第一单元的主题是解析单元变量表达式，可以使用递归下降的解析方法。同时通过三次迭代开发的方式，实现了对含有幂函数、三角函数、自定义普通函数、自定义递归函数以及求导运算等因子的表达式的展开化简。同时，经过中测、强测、互测，以及研讨课交流共性问题等方式，对自己的开发过程进行反思与改进，在第一单元告一段落后，于此撰写以对自己的学习成果予以总结。

二.度量分析

1.度量各类

经由 IDEA 的 Statistic 插件统计，本单元最终代码量为797行即接近800行，而在去掉空行后整体代码量来到708行，近700行左右。个人感觉在代码量上还是足够精简的，因为最终采用了一个较为精巧的架构，在逻辑上部分类形成循环嵌套，架构相近，便于编写。除 Poly 类外其他类均控制在100行左右或以内，只有 Poly 类需要进行大量化简计算，因此所用代码行数会较多，来到142行。

2. OO 度量

经历三次迭代后，最终的UML类图如上。由此可见，本次作业迭代完后的整体架构是以Poly、Mono类，Factor接口为众多因子类所实现的整体为核心，实现了 Poly 类以 Mono 类为容器所用类的成员变量，表达式经 Lexer 类词法分析，Parser 类进一步解析，最后统一通过 toPoly 方法来化简多项式，再经由 toString 这一方法来输出最终结果。

三.架构设计体验

• hw1：第一次由于比较简单，因此直接照搬了 OOPre 的模板，但同时做了一点修改，因为单一的多项式可考虑拆成多个单项，于是考虑使用 Map 类内置容器来进行存储。考虑到输出的美观性，可自由选择 HashMap 还是 TreeMap 来进行设计。本人在第一次作业中因考虑到了升降幂，于是使用了 TreeMap，可以使输出的答案更加美观，同时考虑到一点小小的优化，即以负号开头且有正项的情况下，可以调整顺序以提高最终性能分，作者凭借这点成功在第一次作业的强测中挤进了 A 房，但这也为后来的 BUG 留下了隐患。

• hw2：因为加入了三角函数，因此并不像第一次作业那样解析方便了。因为因子种类的多样性让我的架构设计犯了难。因此我抛弃了 TreeMap 的使用，因为其中涉及自定义类的排序优先级，个人不是特别了解，因此重新换回了 HashMap 的架构设计，因为该容器仅保证映射的唯一性，并不需要多余考虑优先级，可以避免上述犯难。除此之外，值得一提的是自定义函数替换，本人在替换参数注意到了参数的相互独立性，不能直接使用 replaceAll 方法来进行先后替换，否则会出现反复替换的情况导致出错，因此作者采用的方式为逐步扫描，若遇到相应参数即刻替换，而不是先替换第一个参数，再替换第二个参数。

• hw3：在前两次架构的铺垫下，第三次作业显得较为简单，只需依葫芦画瓢，将自定义普通函数与自定义递推函数进行逻辑上的方法合并，最后在相应因子类中分别实现求导方法即可。

四.分析 BUG

hw1 并未出现 BUG. 而在后续两次作业中都出现了较为低级的 BUG.

首先是第二次作业，作者先前提到调换的优化方法。因为是在最后一步，考虑到以负号开头却存在正项，于是将原输出结果进行“腰斩”，再调换顺序拼接，这种简单粗暴的方法在第一次作业情况下显然是可行的，但在第二次作业出现三角函数的情况下，就可能出现拦腰截断三角函数式子的难堪情况。

然后是第三次作业，出现在自己优化性能分的部分。因为想优化掉多余的括号，即三角函数，但误判内部系数的绝对值为正负一即可替换，这一错误较为低级不再赘述。

五.分析策略

本人几乎都是通过给他人 DEBUG 的方式，同时在测试自己的代码时发现的错误。基本上都是通过列举边缘情况与特殊解来进行 hack，同时也借助了 LLM 来模拟数据。

六.分析优化

本人进行的优化较少，仅仅只优化了 sin(0), cos(0) 的情况，同时考虑了同类项合并。除此之外还有多余括号的优化，及判断单因子即可，并无过多优化。

七.心得体会与未来方向

在写代码前一定要三思而后行，同时要善于学习评论区，借鉴他人思路。以及多利用 LLM 来辅助学习，提高效率。希望能将中测的时间再延长一些，同时发布时间早一点，可以多一些准备时间，不用过于匆忙。