BUAA OO 2021 Unit 4 总结

Unit 4 架构设计

在第一第二次作业中，我的架构设计非常面向过程，所有函数全都塞在一个类里，仅有一个唯一的全局 HashMap 管理所有的 UML 元素，并且代码也极其混乱（主要是因为一开始不理解需求，也不理解 mdj 文件的结构）。在第三次代码中，我进行了微量重构：

• 将 UMLElemenet 封装到一个类 UmlElementContainer，并实现
  1. 获取特定 id 元素
  2. 获取特定种类元素集
  3. 获取其 parent 属性为某个 id，且类别为特定种类的元素集
• 将三种不同种类的 UML 图与 UML 规则检查设计为不同的类，并共享同一个 UmlElementContainer。

第一点这么设计，是因为每一个元素都只有至多一个 parent，这对获取某个 id 的全部特定种类儿子是很有帮助的。这里之所以不分别将三种类型的元素拆成三种容器，是因为类图和顺序图都有 UMLAttribute，在建立的时候很难区分。这样，三次作业中所有的操作，都可以用 UmlElementContainer 中的这三个方法依次实现。

具体说明一下第三次作业的判断方法：

• R002：Tarjan 判强联通分量；
• R003：直接从某个点开始向上搜索，出现某个点重复访问则必然重复继承；
• R004：同 R003，只不过这里要同时考虑实现和继承。

架构设计及 OO 方法理解的演进

Unit 1

架构：单纯将类拆分出来。

OO 是将具有相似功能的对象进行抽象与封装，并对之进行组合。例如所有的表达式都是“具有很多项的类”，所有的项都是“具有很多因子的类”，所有的因子都是“具有特定形式或者是表达式的类”，而不关注具体类内部是什么东西。这样，每个类就可以仅关注自己所需要的事情，而无需在意别人的工作，即“单一职责”功能。

Unit 2

架构：开始引入多态。

不同的模式可以有效地解决问题。本单元我使用了状态模式，通过将不同策略转化为一组接口，使得调用过程中能够动态根据策略调用对应动作，即 OO 的多态。此外，多线程的应用让我对线程安全的问题产生重视，并在编写代码时时时注意避免死锁。

Unit 3

架构：由课程组给出。

形式化的语言可以用来规范代码行为。本单元在给出 JML 的规则下进行填空，在理解了规格的情况下可以轻松完成。实现过程中，只要所有前置后置条件完全写清，那么每个方法可以仅关注于自身，而不在意别的方法的具体实现，这很 OO。

Unit 4

架构：由前文给出。

OO 的集大成单元。由于是对 UML 图进行建模，因此这个事情本身就非常 OO（对不同元素的抽象、对不同接口的继承）。在本单元的重构后，我尝试用 OO 的思想去对处理过程解耦，并最大化地抽象接口，也在设计过程中为未来可能的改动留下了空间。俗话说：如果架构修改代价太大，那么就直接重构。我想也是这样的。

测试理解与实践的演进

在四个单元中，我经历了如下几个测试的阶段：

1. 只测样例
2. 手动构造极端样例（集中于第一单元）
3. 相信自己的代码能力弱测中测通过就跑路（集中于第三第四单元）
4. 采用评测机，构造大量的数据进行测试（评测机来自其他人）

实际上，OO 课程是黑箱 + 白箱的混合测试：强测是黑箱，互测是白箱。不过，很多时候大家也是把白箱测试在本地当黑箱测试用，基本很难有人能看完代码，或找到可能出 bug 的地方，因此本质上还是黑箱测试。

当然，第三单元也给出了基于 JUnit 的测试方法，该方法虽然能对代码进行回归测试与单元测试，但是其工作量较大——除非是为了进行严密的正确性测试，否则不太可能为第三单元的代码编写 JUnit 测试。

课程收获

总的来说，OO 课程带给了我许多东西。虽然每次都是几乎在最后一天起早开始 rush 代码，代码没过的情况下还得做极限 DDL 战士，但是这四次作业排布紧密，确实带给了我在架构上的螺旋式上升。此外，我在 OO 课程中了解到了复杂度度量的概念，并据此对代码的耦合与复杂度有了进一步的理解。

OO 的思想其实在很多时候都能用上，并且能够增强代码的可扩展性与理解性。在实际工程中，一定会有面对反复变化的需求之时，也会有团队合作需要分工编写代码之时，这时 OO 带来的良好结果就是令人愉悦的。

课程建议

1. 课程指导书可以更加明确，具有更多的引导性，而不是让同学们不知道自己的需求（比如第四单元）；
2. 课程实验对理解作业有着莫大的帮助，希望能够稍微提前一些；
3. 官方可以考虑在讨论区设置一些自由讨论的话题，引导同学们针对特定问题交流（从第三单元开始基本是同学自发讨论）。