BUAA-OO-2025-UNIT1 总结

张泰尔-23371186 2025-03-21 20:56:51

一、架构分析

1.基本框架

本单元作业迭代中，我采用常见的递归下降方法解析了经过预处理的输入字符串，将其转化成Expr>Term>Factor的表达式树形式。引入Poly>Mono的归一化思路，将整个表达式化为Poly形式并输出。最终代码类图如下：

该结构中，通过Factor（因子）接口实现了多个具体因子，并均实现了向Poly的转化、重写了toString方法（会在函数部分参数替换时用到）等关键方法，新增支持的运算类型时，只需增加一个该接口的实现即可，层次化清晰。同时对各类内部实现的方法进行封装能有效保证架构的可迭代性，例如在Poly乘法中调用Mono乘法实现，这样新增因子需重构Mono时无需对Poly进行修改。

下图是类复杂度情况：

Poly类复杂度过高，考虑到是其中输出方法print()中，为了对输出进行化简（如-1*x^1化简为-x），而设置了过多的分支条件，其实现思路有待优化。

2.架构设计体验

在三次作业迭代中，没有经历过大的重构。

第一次作业：构建了基本的递归下降的框架，并引入了Poly-Mono的形式，Mono属性由简单的系数指数两项构成，并在Poly计算中通过以指数为索引的hashmap完成了合并同类项等基本化简，顺利通过了强测。
第二次作业：因为第一次作业使用递归下降的解析方法，所以实际上已经实现了嵌套括号的展开。新增的三角函数因子，导致了Mono类的较大改动，属性中增加了分别存储sin和cos的两个容器，并且在修改Poly的乘法、加法方法时经历了较大阻碍，经过权衡，最终在mono中选择以ArrayList存储三角函数，并通过逐一比较的方式判断两Mono能否合并。对于递归函数因子，新增了用于记录函数信息的类FuncPattern，其中定义了处理递归函数的关键方法funcToExpr,通过字符串替换的方式实现了函数向表达式的转换。
第三次作业：此次迭代新增的功能相对简单，通过增加FuncPattern类中的方法和属性，支持了普通函数的解析；而求导因子完全可以当作一普通的新因子类型处理，只要写出其向Poly的方法即可。

新的迭代情景：

增加指数函数类型，即指数部分为表达式时，底数部分限制为数字。
可拓展性：只需增加Mono的指数函数属性、修改其判断可合并的方法，并在求导因子中修改求导方法即可实现，无需修改Poly等部分基本框架的代码。

二、BUG分析

迭代过程中，我的程序出现bug的重灾区在于输出化简部分，和函数形参实参替换的部分。

对于前者，我实现输出的方法是对表达式的Poly中的每一个Mono逐一输出，对于每一Mono，进行多次特判，例如系数是1则不显示系数、系数为0则不输出、三角函数指数是0则不输出等。由于特判的分支过多，导致容易遗漏某些情况产生bug。例如出现bug时，sin(x)^0*x我能正确输出为x，但对于sin(x)^0这样只有一个三角函数项的特殊情况时会特判为空串而输出0。
对于后者，由于我函数部分是通过字符串替换的方式实现，导致实现的过程中多次遇到bug，参数无法被正确替换等问题。

反思改进：

出现这样的问题，我发觉化简的程度高，则不出现bug的难度就会大。一方面是因为分支情况难以第一时间考虑周全，二是本次作业中，输入的限制与输出限制不同，例如输出中-x合法，而输入中则不合法，这也导致我产生了许多因为调用输出函数进行“parse”而产生的bug。综上分析，最大的优化点在于print函数的设计，可以通过减少不必要化简、重构分支结构来降低复杂度。

本单元互测中，我通过手动构造数据测试，很少找到其他同学代码bug，也并未结合代码进行针对性分析。

三、优化策略

本单元作业中实现的优化很少，尤其三角函数因子引入后为了输出的正确性舍弃了性能分，没有实现三角函数化简。唯一实现了对"+0"、"*0"和"*1"的输出省略。

经过几次改良最终还是保证了代码的正确性。

四、心得体会

在面向对象课程的第一单元实践中，我对代码组织有了新的认识。最初编写表达式解析程序时，选择直接在表达式树的基础上化简计算，导致添加新功能异常困难。例如想增加三角函数时，发现解析、计算、输出的代码像乱麻般缠在一起，每处修改都可能引发连锁错误。

通过引入继承和多态，我尝试将代码分层管理：在表达式树的基础上，引入Poly和Mono两类，为原表达式每一层都实现向Poly转化的方法，实现了不同变量的归一化。这种结构带来了意想不到的便利。当需要添加求导因子时，我仅需新实现一个factor的接口，并实现其特定计算规则，原有解析和输出模块完全无需调整。递归下降法的运用也实现了意外之喜：第二次迭代时发现已经实现了嵌套括号的处理和化简。。

但这次作业也暴露了我的编码陋习：