OO第一单元总结分析

程序结构分析

类图

设计分析

• MainClass：

主类，程序以此类的main函数为入口开始运行，包含了程序的输入和输出的实现，以及调用Tool类中的优化方法对表达式进行优化

• Lexer：

表达式词法分析器，负责对读入的表达式进行逐字分析，并对判断和读出当前字与跳到下一个字的方法进行实现

• Parser：

表达式语法分析器，是程序的核心，进行表达式的语法分析，并通过递归下降分析法分析生成表达式的各个对象

• Tool：

方法工具类，包含了对表达式进行优化的若干方法（例如删除空白符，缩减连续的符号等）

• Derivation：

求导因子类，包含了求导的相关属性，与求导方法的的实现

• Expr：

表达式类，包含了表达式的相关属性，与合并同类项方法的实现

• Term：

项类，包含了项的相关属性，与项内因子的计算和化简合并方法的实现

• Factor：

因子接口，用于同一化管理不同的因子，包含了求导和深克隆方法的声明，并在下面的各个因子类中进行具体实现

• Fuction：

自定义函数类，用于存放预定义的自定义函数的属性，并实现传参的方法

• Trifunc：

三角函数因子类，包含三角函数的相关属性，并实现接口的相关方法

• Variable：

变量因子类，包含变量因子的相关属性，并实现接口的相关方法

• Number：

常数因子类，包含用Biginteger实现的常数属性，并实现接口的相关方法

代码复杂度分析

• 利用IDEA自带的metricreloaded插件进行代码分析，得到的结果如下：

class	OCavg	OCmax	WMC
MainClass	2.0	2.0	2.0
Derivation	1.0	1.0	4.0
Number	1.0	1.0	7.0
Tool	2.33	5.0	7.0
Variable	1.57	3.0	11.0
Lexer	1.85	4.0	13.0
Trifunc	1.7	5.0	17.0
Function	1.72	9.0	19.0
Parser	4.75	15.0	38.0
Expr	5.2	16.0	52.0
Term	4.4	16.0	88.0
Total			258.0
Average	2.93	7.0	23.45

• 可以看到，Parser，Expr和Term类的复杂度较高，而这三个类也是程序中最核心的类，许多方法的实现和字符串的解析都在这三个类中，故而合理

架构设计体验

第一次作业

目标：通过对表达式结构进行建模，完成多变量多项式的括号展开，初步体会层次化设计的思想

• 第一次作业中，根据要求初步利用递归下降的思想对表达式的结构进行了建模，包含了表达式、项以及因子三个层次，并实现了表达式的读入与分析，项内的因子合并以及项间的合并同类项方法

第二次作业

目标：通过对表达式结构进行建模，完成多项式的括号展开与函数调用、化简，进一步体会层次化设计的思想

• 第二次作业中，在第一次作业的基础上，迭代添加了三角函数因子以及自定义函数因子的实现，并支持嵌套括号的实现，进一步加深了递归下降方法的运用

第三次作业

目标：通过对表达式结构进行建模，完成多项式的括号展开与函数调用、化简，并进行部分表达式的求导，进一步体会层次化设计的思想

• 第三次作业中，在第二次作业的基础上，迭代添加了求导因子，并支持函数定义时的调用定义。若第二次作业的结构合理，此次作业的实现将比较简单，只需加入求导因子类并递归实现每个类中的求导方法

总结

由于第一次作业开始便使用递归下降算法进行表达式结构的建模，使我在后续的迭代开发中无需进行重构，只需在第一次的建模基础上进行添加，并实现新的计算方法即可

bug分析

由于自己比较懒，所以hack别人的次数很少，成功的次数也就更少了，因此在这里主要分析自己程序的bug以及修复的经历

第一次作业

• 本次作业中的bug主要是在对最终输出的表达式进行优化的方面上，包括去除开头的加号，以及最终结果为0的优化

• bug出现的位置在Expr类中的toString方法的重写中，以及Tool类对最后的输出字符串进行优化的方法中

• 出现了bug的方法和没有出现bug的方法相比，复杂度相对较高，代码行数也较多

第二次作业

• 本次作业的bug是在第一次的bug修复中的修复代码在第二次的作业要求中由于不兼容而产生了进一步的bug

• bug出现的位置与第一次相同

第三次作业

• 由于程序架构的设计较为合理，第三次作业的迭代开发量较少，也没有产生新的bug，故没有进行bug修复

心得体会

关于调试

• 第一单元的作业中，让我困惑最久，也花费了巨额时间的是在debug过程中的调试

• 问题出现在一开始，我在某次用IDEA进行调试的时候，发现调试出来的结果和直接运行的结果不一样，调试出来的结果是正确的，而直接运行出的结果是错误的

• 反复的尝试了许多次后，最终发现问题出现在toString方法的重写中，由于IDEA的调试特点，在调试过程中若有toString方法，调试机会自动帮你调用这个类中的toString方法，将这个对象最终的结果显示在调试机中，而我的toString方法中存在着一些化简方法导致在调用toString方法时会改变这个对象中的某些属性，以至于在调试过程中调试机自动运行了额外的toString方法使得程序输出结果与直接运行的结果不尽相同而导致了我在debug过程中的许多困难

• 对于上述问题的解决方法有两种，要么不在toString方法的重写中改变该对象的属性，要么不使用toString的重写（即将原来的toString方法改名，可以叫print或者其他名字）

个人感想

• 第一单元的学习总的来说坎坎坷坷，即使上过上学期的OO先导课，仍然完成的比较困难，也遇到了很多问题，最终的成绩也不是很理想（放弃了优化三角仍然有较多bug）。但在解决问题的过程中也提升了自己的水平和能力，并且对这门课程有了进一步的了解，也在hack与被hack中看到了人心的善恶收获了很多。虽然我认为无偿hack这个设计不是很理想（被hack30多次），但是从另一个角度来看，房友的hack也是在为我们自己的代码查找漏洞，方便我们进一步修复bug。良苦用心天地可鉴

• 希望自己在后续的几个单元里面能够继续学习新的知识，不断提高自己的代码撰写水平和专业能力，并且合理地分配自己的时间，在动手之前先想明白想清楚，会给自己减少很多不必要的麻烦和错误