OO第四单元总结

OO第四单元总结

第四单元总结

13次作业

作业要求

实现UML解析器，可以对类图中的元素进行解析。要求支持实现类图中类的数量统计、方法统计、属性统计（考虑继承）、可见性查询等。

架构要点

本次作业首先要充分理解类图的层次结构，对类、接口与属性、方法之间的关系有充分了解，并对UML中继承、实现、关联关系的具体表示有充分认识，能够区分reference、source、target、assciation、associationEnd等概念。

通过观察可以看出类图中元素大致构成一个树形结构。即一个类或接口包含属性和方法，方法下又包含参数。因此UML类图解析器的结构大致如下图所示。

另一个重要的问题就是维护继承、关联、实现关系。由于本次作业中不需要对重复继承（实现）、循环继承等非法情况做出判断，我没可以直接将这些关系存入对应的类中。

具体地：

1. 对于继承，
   1. 类只能继承一个父类，所以每个类直接维护一个父类即可。
   2. 本次作业中，接口的继承可以“看作”实现，因此将继承存入实现队列中。
2. 对于实现，单独维护一个容器表示类或接口实现的所有接口。
3. 对于关联，单独维护一个容器表示类或接口的所有关联。

注意，在查询类的全部实现时，需要使用bfs搜索并使用hashmap判重以保证时间复杂度。

14次作业

作业要求

要求支持顺序图、状态图的分析。

架构要点

本次作业首先要充分理解顺序图、状态图的层次结构。

类似于上一次，我们可以将顺序图和状态图分别建成树形结构，如下图所示。

顺序图中包含lifeline，message。

状态图中包括region，region中包括pseudoState、finalState、state、transition。

将结构理清楚后，顺序图和状态图的统计相对简单。

需要注意的是，在官方包中，顺序图中的pseudoState、finalState没有继承UMLState类，因此在处理过程中需要特殊处理。而在状态相关的查询中，很容易漏掉以上二者的特殊判断。

15次作业

作业要求

要求支持UML图的合法性判断，判断是否有循环继承、重复继承、重复实现等八种不合法情况。

架构要点

本次作业的难点在于如何判断循环继承、重复继承、重复实现。

我的实现中新加入了两个图。一个图包含所有的继承关系，用来判断循环继承和重复继承。另一个图包含所有的继承和实现关系，用来判断重复实现。

循环继承可以采用Tarjan算法，找出所有大小大于2的连通块，以及所有自环。重复继承和重复实现可以采用bfs+hashmap进行搜索。

架构设计及OO方法的演进

模块化与封装

从面向过程到面向对象。从第一单元到第四单元，逐渐将整体性的算法流程进行拆分和封装。每一个类只需要维护好自己的数据，不需要关心整体数据；每一个方法只需要处理好自己要解决的问题，不需要关心整体算法。

这样的思维方式将复杂的设计架构拆分成具有明确功能的小单元，降低了代码编写和调试的难度，也方便多人合作。

树形结构与数据隐藏

在之前的学习中，数据和操作往往是“平面化”的，即所有数据和算法都位于同一层，由最上层的管理者统一调度和管理，造成上层处理极其复杂。

在第一、四单元中，能够明显感受到，树形架构的好处。每一层管理好自己的数据和方法，不必要的细节对上层隐藏，思维逻辑更加清晰，数据管理更加方便。

理解与实践的演进

工厂化思维

在第二、四单元更容易理解和使用工厂化机制，使用工厂化模式进行更加简单便捷的处理。

生产者与消费者模式

在第二单元中，生产者与消费者模式的理解非常重要。这一单元有助于理解忙则等待、空闲让进、有限等待、让权等待等进程处理思想。

线程安全的极致体验

第二单元作业尤为坎坷，由于多线程运行时有众多不确定性因素。测试过程也存在极大随机性。多次运行结果很可能各不相同。即使多次运行正确也不能确定程序的正确性（据说可以尝试同时开多个线程测试）。

JML工程化设计的优质体验

在第三单元中，根据JML进行具体设计是相对轻松的，但仍然发现有很多细节实现的问题。

课程收获

本门课程可以说是本学期最痛苦的存在，却也是个人收获最丰富的一门课。

通过12次课下作业，可以更好地理解面向对象相关思想、掌握工程化分析方法。同时，也使得个人代码书写更加规范、简洁。

课上测试内容是对教学内容的极大补充，通过实践感受和理解工厂化模式、线程处理、垃圾处理以及UML类图。

我变强了，也变秃了……

具体改进建议

1. 互测环节其实是很能学到东西的，但是由于面向对象课程安排过于紧凑，只有互测的两天能用来学习其他科目，所以对于像我这样的菜鸡来讲，互测环节很难受到重视（毕竟真的挤不出别的时间了……）所以，建议课程组对于作业周期有所调整。
2. 官方包中存在一些问题，使得作业代码的实现变得复杂。比如第四单元中PseduState和FinalState是否可以看成特殊的State使代码实现过程更不容易漏掉判断呢？
3. 指导书不便于查找，中能否在具体实现要求中，将需要实现的指令添加到作为某一级标题，添加到目录中，这样在阅读相关指令信息时可以快速定位，不需要把指导书从头翻到尾。