OO Unit 1
程序结构分析
HW1
-
为了提高可扩展性和减少重构，我在第一次作业按照了支持表达式因子的结构进行构建，将Expression继承自Factor，提前预留出相应接口
-
使用MetricsReloaded分析代码复杂度结果，其中为部分复杂度较高的方法，三栏数据分别为ev，Iv， v，代表非抽象方法的基本复杂度、设计复杂度控制流与其他方法之间的耦合程度、方法圈复杂度
可以看到，解析部分的非结构化程度和类间调用的复杂度较高，耦合较高，难以实现模块之间相对隔离 -
关于类的度量，可以看到圈复杂度的相关数据，这里Term和Parser圈复杂度较高，原因是内部包含了较多的分支判断语句
HW2
- 根据第一次作业搭建的框架，只需向其中增加三角函数的解析部分、求导部分、输出部分即可
- 并对代码进行进一步重构，将大正则转化为按项拆解的模式，单独出一个Splitter进行加减号、乘法的分割代码复用，减少耦合
- UML类图
- 通过分析method的复杂度，我们可以看到进行代码重构后，各个模块各司其职，耦合度进一步降低
- 另外，基于类的metrics可以看到，使用Splitter将部分功能与Parser分离后，两者的复杂度有所降低
- 采用Config类进行功能开关，方便控制已经实现的HW3的功能对HW2带来影响
public class Config
{
public static final String WrongFormat = "WRONG FORMAT!";
public static final boolean TrigoParamRestricted = true;
public static final boolean ExpressionRecursionSupported = false;
public static final boolean PowerIndexInputLimited = true;
public static final boolean PowerIndexOutputLimited = true;
public static final boolean OptimizePowerSquare = true;
}
HW3
- 由于在HW2已经实现了大部分HW3的功能，只需将Config中开关进行相应的变化即可
- 使用分包Package的方法进一步分开各个功能模块，便于管理
- 可以看到，由于部分优化导致代码复杂度急剧增加，基于方法metrics的复杂度分析有所增长，但总体还是变化不大，较大的耦合度是在模型表示方面
Bug分析
HW1
强测无，互测无
HW2
强测无，互测无
HW3
- 写代码前，本地测试时居然找到了HW2的bug！在Term项求导时利用类似于前缀和的方法，动态维护当前导数项能做到O(termlength)求导，但忘记特判求导后能够抵消已有Factor的情况！
- 修改了上述bug互测阶段自己本地又测出了bug！sin（1）这种项（1），在乘法中可以优化省略，但sin（1）中也省略了导致RE！
Hack策略
- 由于完全随机的自动测试效果不太好，前期我只在正确性判断上采用机器判断，而数据构造我是将写代码阶段想到的和预测到的可能数据进行记录，大概160条非常有针对性的测试数据在本地对Room mate程序进行测试
- 但后来发现有些意想不到的看似很正常不刁钻的测试数据却能够偶然抓到一个人，所以后期采用自动生成+手动构造的方法来Hack
对象创建型模式
- 利用工厂方法模式进行重构，将解析部分的parseFactor parseTerm parseExpression 通过传入String来得到相应的数据结构
- 利用工厂来创建可以省略掉Parser部分的类长度和细节处理，进一步降低圈复杂度
心得体会
- 通过仔细思考指导书中利用“组合模式”，将元素和元素组合模式进行分别建模，这样的方法应该是最好的，并且很明显方法复杂度和类复杂度都会很低！
- 但由于HW1就已经按照现有的模式进行构建了，所以并未采用这种方法
- 另外，通过研读他人的代码我发现，自己的代码中能够将每个类进行进一步的划分，我的某些类代码长度竟然达到了300+行，这里面集中了太多的功能，出错的概率太大！
- 最后，单线程面向对象告一段落，接下来将是多线程的面向对象，这里面应该可以用到观察者模式