一,度量分析
•第一次作业
UML类图:
复杂度分析:
第一次作业比较简单,笔者编程时还是面向过程的思想.
读入字符串后,首先将空白项去掉,然后转化"+-","-+","++","--"符号,这样原字符串就变的较为简单.直接使用正则表达式依次提取出每个项.
用ArrayList保存每个项.Xiang类里有求导方法.在main中遍历ArrayList依次调用项的求导方法并连接起来,得到求导结果.
从上图可以看到,此次作业,很多方法尤其是main方法的复杂度和耦合度都比较高.
•第二次作业
uml类图:
复杂度分析:
第二次作业,在第一次作业的基础上增加了三角函数,同时要求判断与空白项无关的Wrong Format.
笔者第二次作业架构与第一次作业基本类似.只是在解析输入的同时增加了判断WF的条件.并在Xiang中增加了三角函数相关的变量和方法.
这次难点主要在化简部分.笔者通过遍历ArrayList查找满足条件的项,按三角函数化简方法进行化简.
这次作业与第一次作业架构类似,但由于难度的变大,复杂度更高了,耦合性也越来越高,第三次作业,笔者最终不得不重构.
•第三次作业
uml类图:
复杂度分析:
第三次作业相比前两次,复杂度大大增加.
这次作业不能再像前两次那样简单的用几个因子表示项.因此,我为每种因子和组合项都创建了类并继承了求导接口,将层次关系抽象化,之后的求导操作很简单了.
此次作业难点主要还是在表达式的提取和化简上,笔者在这两方面都利用了递归的思想.
二,bug分析
•自己的代码bug
第一次作业,在强测中未发现bug,互测时出现了特殊情况下"-+"符号导致的bug.
第二次作业,由于课下偷懒,在强测提交前没有来得及做出评测机,因此在化简时出现了重大bug而没有发现.由于没有注意到对可变对象的修改,一些情况下,化简三角函数时程序会对要返回的引用进行修改.
强测和互测都是这一个bug.
第三次作业,虽然我搭出评测机,但是这次我想当然的以为三角函数内部可以是表达式,导致输入,输出,对WF的判断都出现了问题.并且因为这是审题的原因,我自己的评测机也无法检测出bug.直接导致强测爆炸.
•互测相关
互测时,我主要采用手动构造边际数据的方法,在第二次互测时,我还会利用评测机随机生成较广范围内的数据.
第一次互测中,我找到了一个人输出数据为0时的bug.
第二次互测中,找到了一个人化简"-1"导致项中间出现-sin(x)的bug
找到了一个人错判x**-10000为WF的bug
还找到了一个人无法正常输出常数的问题
第三次强测爆炸,没进互测.
三.总结与体会
第一单元是一个过渡的单元,我在两次实验和三次作业中逐渐走进了面向对象.但我觉得距离真正掌握面向对象的思想,还有一段路要走.以第三次作业为例,在架构时,我抽象了层次结构.但是在解析表达式时,我还是习惯性的用了面向过程的思维.并且工厂化方法我这次也没用到.
第一单元三次作业,由于我的懒惰以及粗心,失去了大量的分数.但是,过去的事没法改变,只有从错误中反思,才能避免犯同样的错误.
在之后的作业中,我要更多地学习掌握面向对象的思维.在前两次作业中,更多地思考拓展性的问题.
同时,尽量在第一次作业较简单,时间比较充裕的时候搭出评测机.