第四单元架构设计
第四单元要完成的是对给定UML元素的建模/统计/分析，考虑到UML元素的组织是树状的，很容易想到基于树状的数据结构完成
由于UML元素已经由官方接口给出，因此结点类采用wrapper的形式简化设计。建图的过程为：
- 根据不同元素type选用不同的wrapper生成对应结点。其实这里类似一个工厂（但是使用工厂的动机不够强烈，因此未采纳
- 将生成的结点放入对应的结点池中
- 考虑到UML图已经固定，没有可预见的动态变更图结构的需求，采用强制离线的方式建图：在所有结点生成完毕后，按拓扑序将结点依次从结点池中取出，完成其向父结点的挂载（mount）过程。4. 为了方便实现中间结果缓存，在父结点完成挂载后显示地调用
setImmutable将其标注为不可变对象，允许保存查询缓存
除此以外，实验性质地尝试封装了一个可以按type对node进行查询的QueryableNodeList类，效果没有达到预期
第二次的三条check全部使用checker类完成，单独根据类与接口的实现/继承关系建立一个有向图并在图上完成相关检测
这次的架构有些over designed，第一次作业对第二次作业的需求迭代方向并没有把控好，好在并没有失控
学期回顾与课程建议
这学期的四次作业下来收获还是蛮多的，在几个不同的场景中深刻审视、理解了一些经典的oo思想，也在实战中尝试实现了一些之前没有机会使用的design pattern，同时也不乏一些自己的实验性质的探索与尝试。总的来说，无论是架构观点还是工程能力，在这学期中都得到了相当程度的锻炼。
对oo特别是java风格的oo的理解更深了。在形式上我们可以简单地说，oo是【继承·多态·封装】，但是实际上这并不能很好地总结oo究竟是什么：js原型链也是一种形式的代码复用，各种追求优雅的语言的闭包特性也可以很好地隐藏实现细节，它们又不是我们所理解的classic oo。smalltalk的oo是纯粹的对象与消息机制，c++的oo是对其他编程风格与特性的补充与完善，swift的oo是面向协议而非面向接口的，而python的oo大有元编程的意味……一千种语言，一千种oo，我们在训练中所熟知的java的oo不过是oo的一种理解角度。所以很难一概而论地说什么才是绝对的oo。所以在这个层面的理解上，我们的探索不仅没有结束，才刚刚开始。
即便如此，无论是广义的还是狭义的，这学期在oo这方面的理解与实践也足够回顾品味了。从最基本的语法特性，到常见的设计模式，到java并发编程，每次作业都是一次全新的工程体验。我们在一次一次的迭代中，在工程这个角度触摸到了oop的初衷：高度复用、易维护、易扩展、人类友好、清晰的架构……
我认为oo课目前最大的好处就是，在压力适度的同时，给我们提供了一个自由探索与试错的机会。同样的一个task，用很直线的方式可以实现，用高度设计的架构也可以实现，哪个实现好，哪个实现不好，在迭代的时候自然就能感受到——欠设计会导致经常性的重构，过设计又会在维护时明显地感到重力——这些都是难得的经验积累的过程。编程的哲学是实用主义哲学与经验主义哲学，因此这些训练对我而言是很有用处的。
在这个基础上，我个人对课程设计有如下几点建议：
- 适当调整难度曲线。比如第一单元在要求熟练掌握正则表达式的同时迅速展开针对oo特性的训练，体验比较陡峭
- 适当调整部分测试数据集，比如电梯第二次作业的构造数据比例远大于随机数据，这导致对一些算法的性能评估出现较大偏差
- 希望能适当增加并发编程的比重，因为这一部分个人认为在生成中相对更重要，而目前的训练对并发安全性、并发性能的涉及程度较轻
白驹过隙，一个学期转瞬即逝。愿来年此时再回首，且听风吟且把酒。