BUAAOO第四单元总结与学期回顾

第四单元架构设计

第四单元要完成的是对给定UML元素的建模/统计/分析，考虑到UML元素的组织是树状的，很容易想到基于树状的数据结构完成

因为UML元素已经由官方接口给出，所以结点类采用wrapper的形式简化设计。建图的过程为：

1. 根据不一样元素type选用不一样的wrapper生成对应结点。其实这里相似一个工厂（可是使用工厂的动机不够强烈，所以未采纳
2. 将生成的结点放入对应的结点池中
3. 考虑到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，用很直线的方式能够实现，用高度设计的架构也能够实现，哪一个实现好，哪一个实现很差，在迭代的时候天然就能感觉到——欠设计会致使常常性的重构，过设计又会在维护时明显地感到重力——这些都是可贵的经验积累的过程。编程的哲学是实用主义哲学与经验主义哲学，所以这些训练对我而言是颇有用处的。

在这个基础上，我我的对课程设计有以下几点建议：

1. 适当调整难度曲线。好比第一单元在要求熟练掌握正则表达式的同时迅速展开针对oo特性的训练，体验比较陡峭
2. 适当调整部分测试数据集，好比电梯第二次做业的构造数据比例远大于随机数据，这致使对一些算法的性能评估出现较大误差
3. 但愿能适当增长并发编程的比重，由于这一部分我的认为在生成中相对更重要，而目前的训练对并发安全性、并发性能的涉及程度较轻

白驹过隙，一个学期转瞬即逝。愿来年此时再回首，且听风吟且把酒。