OO第一单元总结

第一单元总结

第一单元一共有三次课下作业，第一次是多项式求导，第二次是加入三角函数和括号嵌套的表达式求导，第三次加入输入格式判断和嵌套三角函数。

 

（1）基于度量的分析自己的程序结构

以第三次作业的代码为例，总共有12个类，类中属性2-8个，类中方法数1-8个，除了一个求导方法以外，其余方法规模均在60行以内，代码总量在1000行左右

 

循环复杂度分析

本次作业类的循环复杂度较高，尤其是JudgeForm和MainExpression类里执行功能过多，导致复杂度高，内聚性较低，应将其再细分为更小的模块

 

 

类关系及分析

 

 

首先从MainClass类中读入表达式字符串，先用JudgeForm进行格式判断（JudgeForm里功能较多，现在想来应该将其根据具体的功能再细分），再用MainExpression类进行表达式处理，转为后续表达式，转为表达式树和求导运算（应该把这个类细分为多个小类分别执行不同的功能增大内聚性），在MainExpression类中进行树上求导时把每个树节点当作一个Treenode类，但其本质上是简单项Term类，其他类例如Simple类是再输出前进行结果化简，Merge类用来合并同类项。不足之处在于MainExpression中处理的事物太多，导致这个类的代码量大，结构冗杂，不易debug，应将其功能再细分给其他类

 

（2）分析自己程序的bug

第一次作业在互测和强测中未发现bug

 

第二次作业存在三个bug，一个是在ClearZeromulti类中对于输出结果优化*0项写错，第二个是在求导方法里树上加减号节点进行求导操作时出现符号问题，第三个是与-号相关的输出格式有问题，存在--，*-（...），*-x，*-sin(x)，*-cos(x)的问题。相比之下第二个算是较大的bug它所在的方法代码行数较长，难以发现问题

 

第三次作业对于格式检查出现bug，未能检测出sin(+ 30)这种WrongFormat的格式，问题在于JudgeFormat类的结构冗杂，先考虑空格位置错误时没想到这种情况，错把括号认为是多项式，在测试WF也没有测试完全

（3）分析自己发现别人程序bug所采用的策略

第一次第二次就像老师说的深水炸弹一样，把自己在编写代码是认为可能易错的数据记录下来提交上去，但这毕竟不是长久之计，于是在第三次搭建了自己的评测机，对小组成员的java代码进行改编，使其能够文件输入输出，然后再通过C语言写出datamaker来制造数据，值得一提的是制造数据的方法完全按照题目给的要求进行编写，递归生成除WrongFormat的所有可能数据，如下图。将生成数据放入data.in文件中，再编写python程序对生成生成的数据进行求导运算并与java文件生成的结果进行比对，能够完全覆盖除了WrongFormat的数据，不够有一点不足的是无法对输出格式进行检查，例如按题目中要求输出不能*-x这种，但在python中依旧能够正确运算。当发现同学代码出现bug时根据数据去分析他对应地方的代码，找出他出错的原因，以防后续对同一bug进行hack

 

 

（4）重构经历总结

由于第一次作业结构简单，直接统一格式然后用正则表达式去寻找项，进行处理就可以，但是在面对第二次有括号嵌套的时候就没法处理了，于是考虑重构，将输入先转为后续表达式，进而转为表达式树，新引入treenode类，每个树节点可以得到子节点的值和求导的值，这样便可以递归处理表达式的求导结果，有一个取巧的点是由于返回值是一个字符串所以我返回的是“求导#原数”，在上层再利用split处理就可以。得益于第二次重构，第三次在三角函数里嵌套在十行以内便可添加完毕

（5）心得体会

通过第一单元的学习，我确实体会到了面向对象的优势之处，只是自己在运用时还不是太熟练，写出来的代码不乏有很多面向过程的地方，另一点便是对于题目的架构，动手前一定要先花时间去构思好整个代码框架，这样会让自己操作起来得心应手，不会毫无章法想到哪写到哪。