OO第一次博客作业

OO第一次博客作业

一、三次作业的bug反省

1、自己发现别人的问题

（1）输入处理的问题，比如第一次作业，主要就是处理输入的字符串，然后有同学的正则表达式有问题，则对于一些错误输入就不能正确判断。

（2）在求导求完之后的合并项的时候出问题，在第二次作业中我发现了两个同学都是在和并项的时候出了问题，导致两个指数相同的项没有成功合并，然后出现了一些奇奇怪怪的错误。

（3）输入没有处理好，具体到项中各个参数读入的时候会出错，有一个同学x前输入一个空格就没法正确输出。

2、作业中自己被别人发现的bug

（1）使用了大正则来处理输入的格式判断，然后大正则中嵌套了太多“|”导致爆栈问题

（2）求导问题中复制粘贴的有些代码没有及时改正导致的bug

（3）读入每个参数的时候字符串的处理出现了一些问题，比如符号少判断了等等，导致的某一项的某个数据不对

（4）求导完以后合并同类项的过程中出现了问题，导致输出错误结果

3、对出现bug的反省

其实很多bug都是很容易被发现的，但是不知道为什么我就是在互测之前没有发现，然后互测之后才发现有很多很容易就被发现的bug，比如第二次作业中，有三个很容易被发现的bug，然后在互测中身中23刀，然后三个合并修复就解决了。所以自己课下还是要加强对自己代码的测试。

二、基于度量分析程序结构

1、代码度量

（1）第一次作业代码度量

（2）第二次作业代码度量

（3）第三次作业代码度量

2、作业类图

（1）第一次作业的类图

第一次作业纯粹是面向过程的写法，在主函数中调用各种函数，包括判断合法非法、得到指数系数到最后的求导以及输出，都是通过函数完成。

（2）第二次作业的类图

第二次作业在第一次作业的教训之下，懂得要进行结构的设计，加上对同学们讨论帖子的学习，我设计了三个类，分别是项、表达式、计算。通过读取表达式建立一个表达式的对象，然后再表达式内部new项，一步一步把系数和指数拆开，并在项和表达式内部都设计求导的成员函数，最后在计算类内调用表达式的求导，完成输出。

（3）第三次作业的类图

第三次的作业涉及到了递归，所以我是将每一项分别通过add（加）、multiply（乘）、combination（嵌套组合）分别拆开，然后判断是整数、幂函数还是三角函数，然后对于加、乘和嵌套都递归地求导，最后一定能够到单个的或是整数，或是幂函数，或是三角函数的求导，从而完成整个表达式的求导。

3、优缺点自我评价

缺点：这个好多啊T_T

（1）结构还是有混乱的地方，个别的类超过了70行，而个别的类又很短，严重不均衡、不协调

（2）处理输入的方法很笨拙，尤其是判断是否合法，前两次作业使用大正则，这个不是课程的实际目的

（3）代码复制粘贴特别多，很多地方可以复用

（4）没有使用继承和接口，导致代码太长，有很多不必要的地方

　　………………

优点：好像没有

三、自己程序bug和可以改进的地方

1、分析发现的bug

（1）大正则导致程序运行的时候爆栈的问题

（2）项的处理不当导致的数据读入出错

（3）正负号问题的处理，每一个整数或幂函数或三角函数前的符号数量是不一样的，处理时要注意符号的个数

（4）项的合并出错导致结果的错误

2、bug和设计结构的相关性

（1）首先就是第一次作业的结构设计问题，第一次作业还是以面向过程的思维在进行思考，然后就出现只有一个主类和很多函数的问题，不仅导致结构不清晰，也使得代码框架混乱，第二次作业就要重构

（2）使用大正则一次性匹配整个表达式 ，其实一项一项地匹配更有利于代码的扩展，也不会出现爆栈的潜在安全隐患

（3）在作业中使用ArrayList而不是Hashmap，多出来合并同类项的操作，增加错误的概率

四、分析自己发现别人的bug

1、测试策略

　　测试别人的基本策略就是阅读别人的代码，在一些容易出错的地方，比如在一些逻辑复杂的地方（含有多个逻辑运算符的地方有可能会出现枚举不全面的错误）要重点查看。比如第一次第二次的正则表达式的地方就有可能会出现情况的遗漏。

　　有的时候看代码看得头晕也会有点偷懒，就随便构造自己感觉容易错的数据对他们进行测试，虽然命中率不高，但是也不失为一种办法。

2、我没有结合被测程序的代码设计结构来设计测试样例。

五、Applying Creational Pattern

这三次作业难度和复杂度逐步上升，第三次作业可以覆盖前两次作业的功能。对于重构，我认为还是按照之前的结构，逐步递归，但是在对象创建模式上尝试一下工厂模式，将实例化推迟到子类。

最后，虽然这段时间在写作业的时候学了很多，但是发现自己不会的更多，希望以后的时间再接再厉，好好度过接下来的OO课程。