北航OO第一单元总结

[曹伯炜-20373516]

1.架构设计

将表达式解析问题分解为输入、求导、去括号、优化和输出。

具体而言，根据题干的形式化表述明白：表达式=项+项，项=因子*因子，因子包括常数因子，幂函数因子，表达式因子，三角函数因子，自定义函数因子。再基于面向对象的思想，自然而然思考出基本架构，即expression类，term类，factor接口及五种instance of factor的类

针对输入，根据题干提示的递归下降方法，写出lexer类，根据输入的表达式，按照结构分别提取expression，term等内容，交由上述的expression类进一步处理。

有关expression的进一步处理，结合形式化表述：表达式=项+项，建立expression的成员变量:arraylist < term >。同理，term中建立装factor类型的容器arraylist < factor >,在递归下降解析过程中，将表达式拆分成term存入arraylist < term >,将term拆分成factor存入arraylist < factor >。

关于求导，在expression，term和factor中实现求导方法，用类似递归下降的思想，递归求导，求导后正常进行前两次作业实现的去括号方法

2. 基于度量分析程序结构

通过idea插件MetricsReload分析复杂度得到信息

• OCavg : 每个类中所有非抽象方法的平均圈复杂度(继承的方法不计算在内)。
• OCmax : 每个类中非抽象方法的最大圈复杂度(继承的方法不计算在内)。
• WMC : 每个类中方法的总圈复杂度.

可见关于lexer和term的圈复杂度较高，这也是因为lexer需要处理输入，判断逻辑较为复杂，维护成本比较高，一定程度是合理的。而term则是因为拆括号计算主要集中在term层次，需要把factor展开并深拷贝到新的term对象中的arraylist里，具体的实现逻辑繁琐，是需要以后注意并且避免的。

• Cogc : 认知复杂度,其目的是显式地度量可理解性，随着每个控制结构的使用而增加，而且嵌套控制结构越多，认知复杂度就越高。
• ev(G) : 本质复杂度,是一种图论度量方法控制流的结构不良程度的方法。
• iv(G) : 设计复杂度,与方法控制流与对其他方法的调用之间如何相互关联有关。
• v(G) : 圈复杂度,是对通过每个方法的不同执行路径数量的度量，也可以被认为是完全执行方法控制流所需的最小测试数。

关于term类中combine方法Cogc过高的原因是拆括号过程中因子的组合较多，我是用了复杂的嵌套判断逻辑，因此可读性较差，这不利于以后的团队合作，但就正确性而言，影响较小。

而turnString方法的设计复杂度较差，首先明确这只是将已经拆开括号化简后的表达式转换为String类型输出，逻辑本身比较简单，但是具体实现对其他方法的调用较为复杂，导致iv(G)较高

3. 关于bug

对于房间内注重正确性而不注重优化的同学而言，他们的代码中bug较少。我主要发现的bug是进行优化的部分同学代码中的，比如sin(0)**0,部分同学进行了sin(0)=0的优化，他们从左往右分析表达式，识别到sin(0)就转换成0，并没有判断指数，在优化过程中，判断条件的优先级没有想清楚导致出错。

此外，比较知名的bug是深浅拷贝的问题，假如使用浅拷贝，会导致原地址的值被修改后，原来的值丢失，结果自然是错误的，所以群里多次强调需要进行深拷贝。

4. 心得体会

本单元开始时，我还在复习计算机组成缓考，压力比较大，没有及时开始准备第一单元作业，导致第一次作业崩盘，并且OO课程具有迭代的特点，第二次作业，第三次作业在第一次作业的基础上迭代开发，因为我第一次作业的失误导致第二次作业第三次作业更加吃力。所以以后的单元要提前开始工作。

我认为我对面向对象理念的理解不够深入，无法对较为抽象的内容进行面向对象分析，需要在以后的题目中实践中不断感受抽象的力量。

[SoftwareTeacher]

我认为我对面向对象理念的理解不够深入，无法对较为抽象的内容进行面向对象分析，需要在以后的题目中实践中不断感受抽象的力量。

---

希望你可以写博客来总结一下。