OO第一单元总结（博客作业）

OO第一单元总结

一、基于度量分析自己的程序结构

1.第一次作业

UML类图如下

 

 

 

  因为第一次作业比较简单，也是我第一次在面对对象的前提下编程，对面对对象的风格和语法都不太熟悉，所以最后只做了两个类。总体代码量也比较小，没有不必要的代码。

  内聚与耦合：（是我的第一次内聚与耦合分析了，没有借助工具，有点难受）我认为两个模块间，是Dercal控制Regex的控制耦合。Regex模块是一个功能内聚模块，全部为了处理字符串的求导。

  优点：结构简单，利于调试和修改。而且模块的内聚度较高。

  缺点：内聚度越高越好，耦合度却不能太高。显然在我第一次使用class这种面对对象的功能时，对耦合度的控制不太好，甚至差点写成了内容耦合。这体现出了我对封装这个概念还是不太理解。

2.第二次作业

UML类图如下

 

  第二次作业加入了三角函数和有多个因子组成的项这个概念，在听了老师在课上的讲解与分析后，我完成了这个由5个类构成的程序。第二次作业时，我已经对抽象出对象的这个概念有了大概的理解，再加上有了第一次作业的经验，我对类的设计更加成熟了。不过当时我并没有学会继承与多态，所以这次的代码里其实有很多没必要的重复。主要出现在Power和Trigon两个类中。

  内聚与耦合：Main 函数对于其他函数全部是控制耦合。其他类之间均为标记耦合或数据耦合（这两个我有点分不清）。这次的内聚度，我觉得只能算过程性内聚，因为不仅有求导功能，合并同类项等功能也均放在了同一个模块中。

  优点：类分的比较清晰，清楚的直到哪个功能应该由谁来执行。

  缺点：我觉得这次耦合度基本及格了，但是这次的类抽象的不够好，再加上为了完成性能优化，我在类里放了很多其他方法，导致内聚度下降。其实这些应该单独放在一个类里。其次，这次为了方便自己，在类中设置了大量的get某属性的方法，让封装性也不太好了。

3.第三次作业

UML类图如下

 

  第三次作业的复杂度明显高多了。加入了嵌套结构，导致整个过程从原来的单步求导变成了递归下降的结构，对类的设计也有了严格的要求（不然做不出来啊）。我采用的设计思路是上课时老师提供的那种，即把整个表达式分为乘组合项，加组合项和嵌套结构，单独的项又有幂函数，三角函数和常数。整体代码量来看，我自己还是比较满意的，尽量比较少，而且结构比较清晰。不过这次我没有完成优化，因为实在时能力不足。

  内聚与耦合：这次因为有了继承，我感觉整体都达到了数据耦合的程度。内聚也是功能性内聚（可能是因为我这次没优化？）。

  优点：结构清晰，一层套一层，最后一个递归求导直接解决。内聚性高，加入了InputHandler，模块只负责求导，处理字符串有InputHandler负责。

  缺点：优化写不出来，并且仍然用了大量的get导致封装性不高。

二、bug分析

1.第一次作业

  bug1：不能识别由\f\v带来的格式错误。原因是我误解了题意，我以为指导书的意思是\v\f不能出现在测试样例中。

  bug2：不能识别x^ + 2的格式错误。原因是我在用正则表达式识别空格错误时，忘记在^和[+-]之间加空格。

2.第二次作业

  强测和互测未发现bug

3.第三次作业

  bug1：不能识别指数前的加号。原因是我处理字符串时没有考虑完全，跟设计结构没什么大关系。

  bug2：如果字符串第一个字符是'-'的话，求导正负号会错误。原因是我在修改代码时有一句if忘记删了，导致会多加一个'-'。

三、发现别人bug所用的策略

  我基本上全部时黑盒测试。第一次作业因为代码量少还好，越到后面想阅读别人的代码花费的代价就越大……

  测试的基本思路是根据一些易错点做样例。覆盖性不全，也不容易发现bug，感觉我互测这部分其实完成的不太好。

四、Applying Creational Pattern

  如果让我重构代码的话，我可能会选择建造者模式来重构。因为我自己大概用的是工厂模式，虽然求导挺快的，但是最后造成了难写优化的问题。

  并且我会把部分继承改成接口，因为我的Multi类感觉是强行加上去的，只是作为一个父类，不如把求导函数改成接口的形式，很方便。