OO前三次作业总结

第一部分：代码分析

第一次作业：

整体的类图如下所示

 

方法和类的复杂度分析：

第一次作业中具有两个类，主类负责读取输入的字符串并传递给poly类，而poly类中具有对输入数据合法性的检查，二元组的数据存储，对二元组的求导操作，以及合并同类项的化简操作。这些操作又是由一些基本的操作如提取数字，提取符号等基本操作构成。

本此程序的优点在于考虑了大正则会爆栈的问题，采用了分项处理的方法，从而避免爆栈问题。

缺点在于处理时并没有使用HashMap而是采用了两条ArrayList并行的方法，这样降低了二元组的内部耦合性，提高了出错的可能。同时在设计类时将过多的处理过程丢到了一个类当中，造成了类的结构冗杂，不易阅读，也不易理解。

在程序复杂度方面可以看到，在判断符号以及判断如何输出时，由于情况较多，所以导致判断分支较多，这样的程序事实上是非常难以debug的，过多的不满足容斥原理的分支会导致人脑无法完全而又不重复的列出所有情况。而在类的复杂度方面，正如刚才所言，Poly类的复杂度过高，并没有将其中一些基础功能再进行分类。

第二次作业

类图

方法以及类的复杂度

 

第二次作业的大体思路就是按照指导书所描述构成表达式的三层逻辑构造三层类，表达式的生成也是按照各层逻辑逐层生成，最基础层是factor，存储有自己的类别（sin() cos() x^n等等），同时具有自己的求导方法，返回作为factor求导的表达式字符串。之后上两层则分别具有其下两层的ArrayList，最后得出结果是靠*或者+将其连接起来得到最终表达式。

优点在于本次作业花了相当长的时间进行了结构设计，虽然最后只设计出了相当平庸的三层逻辑，但是在思考时进行了很多尝试，同时看到除了输出和优化（优化后来被注释掉了没有采用），其他的方法的复杂度都相对较低，说明程序的可读性以及逻辑清晰度都变得更加清晰了。

缺点在于这次作业的封装做的非常不好，没有用好继承与接口，在一个factor中具有大量的private 数据（因为不同的类型会用到不同的数据。这样就会造成大量浪费）同时在输出的逻辑上做的还是不好。之后的很多bug还是处在输出身上。

关于复杂度这次做的还好，除了输出的逻辑较为复杂，其他方面的结构化程度，类耦合度，以及递归深度都做的还好。

第三次作业

类图

方法以及类复杂度

第三次作业写得十分的艰苦，林林总总加上构思写了四天才能够写完，同时如何处理输入的数据这种问题给我造成了极大的困扰，因为之前并没有十分深入的了解过递归下降这类的递归算法。所以在构思时具有很大的困难。同时如何将表达式的各项提取出来以及将各因子提取出来也具有很大的困难。最后按照各层的+和*将表达式分离了出来。

这次作业的问题在于并没有十分清楚的考虑到所有的情况以及递归的滥用。首先就是按照符号划分各层就必然会面临会具有很多的特殊情况，这样的情况就会导致如果没有仔细思考可能出现的情况，那么会出现处理上的WF出现。另一方面，在判断内部是否是正确形式时，滥用了递归，这也导致了强测时很多数据点都出现了超时。

另一方面我认为在写程序期间，保持良好的休息也是必要的，只有休息好了，才会有良好的精力去构造结构更加合理的程序。

复杂度方面可以看到由于滥用了递归，所以我的build方法复杂度各方面都很高。

 

自己的BUG的分析

第一次作业的bug和第二次作业的bug都在于输出时逻辑过于混乱，所以有时+  1   -  0这些特殊情况会出现不合语法的情况。

第三次作业的bug主要出分层剥离时，会出现由于 * +1 或者单独出现 * 的情况，这些都是我之前没有考虑到的，其次就是由于在判断内部是否满足语法时，滥用了递归，导致程序运行时间过长，这都是比较致命的bug。

 

发现bug的策略

主要是分为两方面，前两次作业集中在通过阅读自己的正则表达式以及正则表达式之间的链接通过 增加  删去 重复 等手段构造一些非法数据， 另外就是构造诸如0 这样的特殊数据。

第三次作业的bug主要在于设计一些递归层数较深的数据，以及项和表达式不完整的式子。

 

重构思路

就我目前掌握的知识来说，不太好确定如何重构。我希望在接下来的作业里能用好继承，接口这些性质从而能够写出更加像是面向对象的代码。