第四单元架构设计
由于需求基本上都是查询操作，故把重点放在UmlElement的处理上，并尽量实现初始化时就完成需查询量的存储，减少查询时的复杂度。具体来说，就是实现一个Manager类来完成初始化操作，并新建一系列UmlXXX类来满足需求。
三次作业基本实现了迭代开发，对于新增元素，只需在Manager类中实现对新增元素的处理，再实现Interaction类里的查询方法即可。
UML图：
架构设计及OO方法理解的演进
- 架构设计从无到有
相较于第一单元多项式时几乎每一次作业都要进行一次痛苦的重构，第二单元电梯作业时屡屡修改的电梯类，第三四单元时基本都能实现了增量的迭代开发，对核心类基本都没有大幅度的修改。
2. 真正理解架构的设计原理与具体实现方法
第一单元时我对架构的可拓展性一直有个误区，那就是觉得这必须依靠对需求的可预见性，而由于自己思考的不足和对优秀架构设计认识的缺陷，我曾认为这只能通过投机取巧的方法实现——通过阅读往年的指导书来“预知”需求。但经过后面几个单元的洗礼和一些优秀代码的阅读，尤其是第三单元JML中相当于现成的架构的迭代，我对才真正对架构设计有了一定的理解，并在第四次作业中实现了完全的迭代开发。至于具体的心得，就像我在第二单元的总结里说的那样，
毕竟这门课的名字是“面向对象设计与构造"，而不单单是”面向对象编程“。我相信学习优秀的设计模式并掌握构造优秀架构的能力才是对我们最终的要求。
设计应当是第一位的。新的需求永远是未知而多变的，而我们不可能永远拥有“预知”需求的能力。落实到代码实现层面，那就是在coding前进行充足的构思和分析。
3.从面向过程到面向对象
尽管自己对面向对象仍旧是管中窥豹，但相比前两次作业时对于新增需求实现时第一反应的构造一个十分面向过程的静态类、静态方法，在第四次作业时我的第一反应已经是分析要不要新增类、类之间的关系如何了，我想这就是我对OO方法理解的最直观的表现。
测试理解与实践的演进
在第三单元之前，自己的测试基本都是靠实现自动评测机和构造边界数据实现。但在第三单元学习了JUnit的相关知识后，对测试有了进一步的理解，并运用在了第四单元作业的测试中。但有一点我不得不反思，那就是在互测中针对性的hack太少，没有通过面向代码来hack，而是期望于自动生成的数据，这样效率反而降低了。
课程收获
- 不用多说，自然是面向对象的相关知识。
- 多种优秀的设计模式、设计原则、架构。
- 每周日紧张刺激的互测。
- 研讨课上收获颇丰的干活。
课程改进建议
- 实验课改进空间仍然很大。首先是实验本身的体验往往不是很好，指导书中总是出现一些影响理解的错误。其次是实验课的反馈太少，既没有正确答案，也没有自己的成绩或是错误的公布。但是还是要感谢助教的付出，实验课确实能学习到很多知识。
- 单元内不同作业的梯度还不错，但是个别作业内中测与互测的强度梯度过大，有种中测=没测的感觉。
线上学习OO课程的体会
由于我也没有在线下学习过OO课程，所以体会可能不是很准确。就理论课而言，感觉多数是线上学习的通病——效率不高、知识掌握不牢固等等。课后作业与实验总体来说与线下区别不大。