OO第四单元及课程总结
OO第四单元及课程总结
架构设计
总体实现的类图如下
总体思路就是功能的分发，由一个总类把各个UmlElement视类型分发到类图处理类，顺序图处理类或状态图处理类。再由各处理类检查正确性，新建MyClass等结构，并进一步分发给各结构进一步处理。管理访问中由于需要从id到具体元素，故大量采用了Map结构。
为了省空间，各个MyClass等包装类没有继承UmlClass，而是选择了组合的方式，一个MyClass对应一个UmlClass（而且有的包装类并不需要原来的UmlElement，如MyParam中只用存各个参数的类型即可）。
各个包装类的设计思路也完全根据接口的方法需求来设计，比如需要接口中有查询消息数的方法，MyLifeline中便可以只用Map<MessageSort, Integer>来计数。
四个单元中架构设计及OO方法理解的演进
| 单元 | 架构设计 | 主要OO方法 |
|---|---|---|
| 一 | 输入解析部分用一个解析类处理构建。 具体化简求导部分采用接口抽象和组合结构，各个实现类分别实现相应方法。 |
用接口抽象每个项，充分利用多态性，建立抽象层次，工厂模式。 |
| 二 | 多线程采用生产者消费者模式。 总体结构采用组合的方式，分派器管理调度器，调度器管理电梯。 电梯采用简单的自动运行方法，指令顺序由调度器决定，指令由分派器决定。 |
层次化，状态模式。 |
| 三 | 总体结构采用组合的方式。 | 层次化 |
| 四 | 完全依赖需求的组合方式设计，逐步分解分发接口方法。 | 层次化 |
总的来看对OO方法的理解演进主要是在第一单元，而后的几个单元最多是对层次化的应用，并没有采用其他的一些模式。第二单元中简单了解了一个状态模式，但由于电梯状态不多，比较简单，也没有实际使用。多态性的应用也只有第一单元有所使用，之后的几个单元出于性能考虑都是按照需求来进行的架构设计，扩展性较差。
四个单元中测试理解与实践的演进
| 单元 | 测试理解 | 测试实践 |
|---|---|---|
| 一 | 知道了要构造边界数据测试，覆盖样例的所有情况，和随机生成器生成大量样例测试；增加新功能后需要保证原来的测试也能通过 | 边界测试，特殊数据测试；表达式随机生成器大量测试；回归测试 |
| 二 | 学习了多线程测试，测试中增加了各线程所占的CPU时间考察这一项，即需要测试有无轮询 | 手动构造样例测试；回归测试 |
| 三 | 认识到规格对单元测试的和样例覆盖情况的指导作用，知道了根据规格进行的形式推理验证正确性 | 分析规格中的null等条件手动推理验证；基于规格的覆盖性单元测试 |
| 四 | 无 | 手动构造样例测试；单元测试 |
总的来说最具有价值的还是规格指导的单元测试，因为程序规模大起来之后，有很多功能其实可以看成是独立出来的，而写的时候又容易不注意null等，而单元测试和规格可以很好的解决这一问题，快速排查有问题的方法等。生成器的覆盖由于时间并不充分，故只有第一单元有实践，后几单元的生成器都比较难写，而且验证起来也难，只能对拍或是找网上已经验证过的验证器。
课程收获
- 学习了架构设计和层次化思想
- 训练了多态性的应用
- 学习了多线程的编写
- 学习了不同的测试方法和思想
- 学习了规格和单元测试，用于应对大规模的程序
- 学习了UML建模语言和思想，大致知道了如何从对象和关系去描述一个问题
- 学习训练了代码风格规范
课程改进建议
- 有些指导书上的描述还是会存在不清晰的现象，建议在第三单元之后的作业都加上相应的规格（当然规格描述比较复杂的可以只写一下前置条件后置条件等）
- 感觉对面向对象的一些设计模式训练得还不够，除了第一单元的工厂模式和第二单元的策略模式之后，后几个单元几乎就是普通的组合就可以搞定，建议后两个单元也出一些比较适合特定模式的情景，加深对各种模式的理解应用。
- 没有专门讲测评机的构建，建议出一个专门的测评机构建的作业与讲解（不强制的话真得调动不太起积极性）
