OOUnit1博客作业

一，程序分析

1，第一次作业

第一次作业十分简单，表达式中只会出现常数因子和指数函数因子，且不需要考虑WrongFormat的情况,求导规则也是最基础的。下面给出第一次作业的UML类图以及复杂度分析。

UML类图：

方法复杂度：

类复杂度：

可以看出，在第一次作业的时候，我还是保持这面向过程的思想，实际上第一次的作业就是一个带一个结构体的一Main到底的C语言程序，因此我的Main()方法平均循环复杂度过高是显然的。其中我使用的creatMap()方法耦合度过高，且Item重写的toString()方法和creatMap()方法圈复杂度都过高难以维护。

2，第二次作业

第二次作业在第一次作业的基础上增加了sin,cos两个三角函数，要求进行不包括空白字符的WrongFormat判断，同时在第二次作业中增加了乘法求导规则，允许一个项由几个因子相乘得到。在第二次作业中，老师强调要给第三次作业留下改进空间，因此，这次作业中，我尝试着多建了几个类，同时在对求导方法的处理上，考虑到之后可能会有递归求导（指导书明示），在求导方法上我采取的是递归求导。下面给出第二次作业的UML类图以及相关复杂度分析。

UML类图：

方法复杂度（部分）：

类复杂度：

可以看出在第二次作业中，有了一定的面向对象的思想，但是各方面的问题还很多，有很多方法基本复杂度都较高如：multiply(),merge()等方法，较高的基本复杂度不利于代码的阅读和理解是需要改进的部分。ExpressionParser的parse()方法的耦合程度较高，OutProcess类的平均复杂度较高。

3，第三次作业

第三次作业在第二次作业的基础上增加了因子的嵌套，同时要求处理空白字符的WrongFormat，总的来说，求导等方面与第二次作业差别不大，第三次作业难点在于如何读取嵌套结构的因子。最终，我采用的是递归处理。下面给出第三次作业的UML结构及方法和类的复杂度。

UML结构：

方法复杂度：

类复杂度：

可以看出，这一次的作业主要的问题就是在读入数据的处理上，ExpressionParser类以及creatExpr,creatFact方法都非常复杂。此次作业对于WrongFormat的处理也不够好，因为第二次的作业没有嵌套因子，所以第二次只需要用正则表达式就可以进行格式判断，但是第三次作业因为有嵌套因子的存在，不能简单地使用正则表达式处理，只能进行递归处理，而我由于时间不足，延续了第二次的处理方式，只能考虑在创建因子的同时进行格式判断，出现了很多exit(0)这类处理方式，使得代码非常难读懂且难以维护。

二，BUG及优化

由于第一次作业非常简单，在公测及互测中都没有出现BUG且优化也十分简单，所以掠过。

1，第二次作业：

在第二次作业中，我进行了一些简单的优化，如：合并同类项、将cos(x)**2+sin(x)**2这种类型的三角函数化简等，但是最后，我看到讨论区中指出x**2如果化简为x*x会更短，我也没有仔细思考就直接对最后的字符串进行了将x**2替换为x*x的字符串进行处理，导致强测和互测中出现了非常多的BUG。互测中发现一部分同学对空串没有进行处理。

2，第三次作业：

在第三次作业中，我没有进行优化（原因是没有在第三次作业上投入足够的时间），第三次作业也出现了BUG：链式求导时，对ArrayList使用了remove()方法，但是忘记了这个数据结构需要多次使用，导致最后出错，以后要注意多使用clone()方法，避免对数据的隐性修改！！！！

3，对于他人BUG的发现：

目前主要采用的方法主要有三种：

• 读代码，主要读对于输入的处理以及求导。

• 测试边缘数据，如：空串、---x、-x**+0等等。

• 在第三次作业中，也可以测试多重嵌套数据，如：(((((((((((-x)))))))))))等。

三，对比与体会

• 面向对象的思想：虽然在我的这三次作业中体现了一定程度的面向对象的思想，但是总体来说，还是有所不足，比如数据的读取以及格式正确的处理，都是纯粹的面向过程，而在优秀代码中，很多同学都采用了工厂模式。

• 评测机的搭建：没有评测机，在检查自己的代码和别人的代码时会非常麻烦，这一点在这三次作业中让我深有体会，在下一次的作业开始前，我最好能搭建自己的评测机。

• 作业要预留足够的时间：第三次的作业，我是周六早上开始写的，这也导致了我没有进行优化且bug很多，这些都是可以避免的，如果早一点开始工作，最后的作业也会更好，也能让我学到更多东西。

•