OO第四单元及课程总结

Posted 2021-06-24 Kyle-Kirsten

目录

• OO第四单元及课程总结
  • 架构设计
  • 四个单元中架构设计及OO方法理解的演进
  • 四个单元中测试理解与实践的演进
  • 课程收获
  • 课程改进建议

OO第四单元及课程总结

架构设计

总体实现的类图如下

总体思路就是功能的分发，由一个总类把各个UmlElement视类型分发到类图处理类，顺序图处理类或状态图处理类。再由各处理类检查正确性，新建MyClass等结构，并进一步分发给各结构进一步处理。管理访问中由于需要从id到具体元素，故大量采用了Map结构。

为了省空间，各个MyClass等包装类没有继承UmlClass，而是选择了组合的方式，一个MyClass对应一个UmlClass（而且有的包装类并不需要原来的UmlElement，如MyParam中只用存各个参数的类型即可）。

各个包装类的设计思路也完全根据接口的方法需求来设计，比如需要接口中有查询消息数的方法，MyLifeline中便可以只用Map<MessageSort, Integer>来计数。

四个单元中架构设计及OO方法理解的演进

单元	架构设计	主要OO方法
一	输入解析部分用一个解析类处理构建。 具体化简求导部分采用接口抽象和组合结构，各个实现类分别实现相应方法。	用接口抽象每个项，充分利用多态性，建立抽象层次，工厂模式。
二	多线程采用生产者消费者模式。 总体结构采用组合的方式，分派器管理调度器，调度器管理电梯。 电梯采用简单的自动运行方法，指令顺序由调度器决定，指令由分派器决定。	层次化，状态模式。
三	总体结构采用组合的方式。	层次化
四	完全依赖需求的组合方式设计，逐步分解分发接口方法。	层次化

总的来看对OO方法的理解演进主要是在第一单元，而后的几个单元最多是对层次化的应用，并没有采用其他的一些模式。第二单元中简单了解了一个状态模式，但由于电梯状态不多，比较简单，也没有实际使用。多态性的应用也只有第一单元有所使用，之后的几个单元出于性能考虑都是按照需求来进行的架构设计，扩展性较差。

四个单元中测试理解与实践的演进

单元	测试理解	测试实践
一	知道了要构造边界数据测试，覆盖样例的所有情况，和随机生成器生成大量样例测试；增加新功能后需要保证原来的测试也能通过	边界测试，特殊数据测试；表达式随机生成器大量测试；回归测试
二	学习了多线程测试，测试中增加了各线程所占的CPU时间考察这一项，即需要测试有无轮询	手动构造样例测试；回归测试
三	认识到规格对单元测试的和样例覆盖情况的指导作用，知道了根据规格进行的形式推理验证正确性	分析规格中的null等条件手动推理验证；基于规格的覆盖性单元测试
四	无	手动构造样例测试；单元测试

总的来说最具有价值的还是规格指导的单元测试，因为程序规模大起来之后，有很多功能其实可以看成是独立出来的，而写的时候又容易不注意null等，而单元测试和规格可以很好的解决这一问题，快速排查有问题的方法等。生成器的覆盖由于时间并不充分，故只有第一单元有实践，后几单元的生成器都比较难写，而且验证起来也难，只能对拍或是找网上已经验证过的验证器。

课程收获

1. 学习了架构设计和层次化思想
2. 训练了多态性的应用
3. 学习了多线程的编写
4. 学习了不同的测试方法和思想
5. 学习了规格和单元测试，用于应对大规模的程序
6. 学习了UML建模语言和思想，大致知道了如何从对象和关系去描述一个问题
7. 学习训练了代码风格规范

课程改进建议

1. 有些指导书上的描述还是会存在不清晰的现象，建议在第三单元之后的作业都加上相应的规格（当然规格描述比较复杂的可以只写一下前置条件后置条件等）
2. 感觉对面向对象的一些设计模式训练得还不够，除了第一单元的工厂模式和第二单元的策略模式之后，后几个单元几乎就是普通的组合就可以搞定，建议后两个单元也出一些比较适合特定模式的情景，加深对各种模式的理解应用。
3. 没有专门讲测评机的构建，建议出一个专门的测评机构建的作业与讲解（不强制的话真得调动不太起积极性）