OO第一单元做业总结

oo第一单元的做业是对多项式的求导。下面就是对三次做业分别进行分析。

第一次做业

分析

第一次做业相对来说比较简单，甚至不用面向对象的思想都能十分轻松的完成(实际上本身就没有使用)，包含的内容只有常数项和指数项。实际上此次做业给个人最大收获是初步认识了正则表达式的使用。程序的结构以下：

设计

结构十分简单，只有一个类(就是面向了过程。。。)，类的构造函数用以处理输入的字符串，calcDiff()用来计算导数。

度量分析

从表格中能够看出来，factor()方法的复杂度与独立路径条数较高，这是由于这个方法中进行了太多的if-else判断，代码的分支条数太多，致使代码可读性不高。

强测

此次比较失误的是没有仔细审好题目，觉得++x这种操做是不合法。致使扣了必定的分数。

总结

本次做业难度不高，对于刚刚学java的菜鸟仍是十分友好的，但因为对面向对象的思想仍是比较陌生，因此写出来的代码确实不忍直视。可是收获仍是有的，好比学会了正则表达式等工具。

第二次做业

分析

此次做业明显就要比上一次的做业难度上有了很大的提高。以及老师在周四的课堂上最后说了一句，“以为第一次代码写的不行就赶忙重构吧，不然第三次做业是必定过不了的”。因而乎果断重构了代码。经过揣摩指导书(提醒了此次做业三角函数中只有x这种变量)，我提早预判到下次做业多是复合函数求导hhh，因此在构思的时候就把复合函数考虑了进来，在factor类里增长了一个expression类型的私有属性。

设计

UML图以下：

与第一次做业相比，此次的设计要复杂的多，也有了面向对象的影子。

度量分析

此次有好几个方法的V(G)值很高，一部分缘由是由于我考虑了factor中存在expression的因素，致使多了不少分支判断。另外一部分缘由是由于在作输出优化的时候没有想清楚具体的优化方法，单纯一味的if判断。

总结

由于此次所设计的需求超过了实际需求，因此耗费了不少的时间，但也为下次做业节省了很多时间。同时此次做业的测试规模已经十分之巨大了，因此我也学习了一下规模化规范测试的方法，用Junit进行了批量测试。

第三次做业

分析

实际上此次做业在发布之初我就很是的兴奋了，由于基本符合了我在做业二时所作的预判，总算没有白费功夫。。因此实际上个人代码结果和上次来说基本类似，花费的时间也比较短暂，一天就完成了这次做业。比较大的区别就是在于输入判断这块，因为factor里面还有expression，这种带括号的文法是没法直接用正则表达式进行匹配的，因此个人解决方法是进行迭代处理。好比像sin((xcos(x)))这种Term，我是先将内部括号代换成x即sin(x)，以后判断外层语法是否正确，而后在将(xcos(x))代换回来，等到factor内部的expression再进行判断。

设计

UML图以下：

整体思路和上次一毛同样，就是修改了一些细节以及增长了一些用来优化的方法。

度量分析

总结

实际上个人这个设计上是有很大的缺陷的，实际上像加减乘除运算都应该从factor，term，expression类中抽离出来，单独作一个运算类，高内聚，低偶和。而我如今所作的并无达到这一目的。因此每次修改一个类的方法都会致使一连串的连锁反映，这也致使以后在强测的时候发现有一处判断没有修改而出现了错误。代码的可读性也差了不少。

Bug分析

三次做业的bug主要出现的位置就是在输入处理和优化上面，输入有审题不认真致使也有边界考虑不周全致使。这部分的处理确实十分的棘手也很麻烦。只要思惟稍有不连惯性就颇有可能出现了bug。优化上的问题从根本上考虑就是设计上的缺陷致使，没有很好的分析清楚各个类之间的继承关系，致使每一个类内的书写很是的累赘。

分析本身发现别人程序bug所采用的策略

实际上我没有刻意的去挖掘他人的代码缺陷并精心设计针对性的测试程序，仍是主要使用的黑盒来进行测试。在测试时，我编写了一个自动生成测试用例的脚本(sympy进行验证)，来测试代码的正确性，会不会爆栈等。同时也人工设计了一些格式上有问题的数据来检测程序的输入处理上是否有问题。

Applying Creational Pattern

前两次做业由于功能相对简单，在没有建立模式的概念下也能比较舒服的完成。但第三次做业的时候就感到十分不舒服了。若是要让我重构的话，我以为我会建立一个接口类以及常数类、三角函数类、表达式类、项类。用接口类给出不一样的运算接口。而后再在每一个类中实现它。

总结

这三次做业作的确实都比较仓促，因为还有别的一些事情，没有花费足够的时间在这上面，以后应该多花费时间在面向对象这门课来。

不过经过这三次做业，我对Java语言的掌握程度提高了不少，也对面向对象编程有了进一步的认识，逐渐摆脱了面向过程的思想。更加注重程序的可扩展性和鲁棒性。