面向对象设计与构造第四单元总结以及课程回顾

[jiaoziqian]

总结本单元所实践的正向建模与开发

最终的类图

建模与开发过程

回顾整个建模过程，我一开始想尝试在开始写代码之前就把整个架构设计好，画出类图，但是经过半天多的尝试之后发现效果并不明显，只能大概写出几个类名，以及一些属性名，删删改改总觉得不对，而且最后实现起来发现有些类以为有用其实没用（比如我一开始在书籍副本之上设计了“书籍模板”类，用来管理同书号的书籍，但是发现其实没有必要，直接统一管理所有书籍即可），还有的类开始就觉得没必要但是后来发现加上这个类实现会舒服很多（比如学生类，一开始觉得图书馆只需要记录书籍的位置和持有者就可以，没必要从学生的角度去索引，但是后来发现还书等操作还是有以学生为索引的列表更好操作，有点像页表和反置页表那种感觉）。

所以最终还是画出没有方法的草图就开始实现了。说实话我觉得这单元的任务从实现的角度来说难度确实很低，尤其是已经经过前三个单元训练之后。但是我也意识到自己的设计能力还是不太行，对数据和行为的抽象还是不太够，多数情况要采用“缺啥写啥”的边实现边设计，这里缺一个零件就造一个，如果发现有比较相似的行为或者数据再考虑抽象一下，但是这样确实可能会错失设计阶段直接划分好抽象，直接最大化利用所有结构的可能性（这多少有点理想了，至少我现在还远做不到不走一步就看出全局，还是菜，得多练）。

总结本单元作业的架构设计，并对比分析最终的代码设计和UML模型设计之间的追踪关系

架构设计

这次整体的架构我自我感觉还是很不错的，各个类的职能划分比较明确，也没有出现跨层次依赖的情况，特别是在迭代时加入漂流角（作为书架的子类）和非正式书籍复印件（作为书籍复印件的子类）两个类的时候，只加了很少的一点代码，感觉自己这个架构的可拓展性还挺强的。

对于具体的架构，我对类的划分就是基于实际需要，基本上就是回答一个问题——“图书馆里有什么”。首先是一个控制类（相当于图书馆中枢）Library，然后就是图书馆的各个部门，负责完成各种功能，由控制类分配指令和调度协作，此外就是书记副本类和学生类，以及为了更好存储预约信息建立的订单类。

追踪关系

基本上就是一开始画了一个简单的草图（类图的一部分），然后根据这个设计尝试实现并在实现过程中随机应变，然后再将代码中的变化反馈到类图中。

至于状态图和顺序图基本都是根据代码后续补充的。一开始对书籍状态变化的设计基本就是基于位置的，没有特殊的设计，而对于顺序图确实没有提前设想，是写完之后才画出来的。

总结自己在四个单元中架构设计思维的演进

1. 从“平面”到“立体”——抽象层次架构的熟练掌握
   一开始我的类设计总是类似于一个“平铺”的状态——各个类之间没有上下级关系，只是平级合作，但是在多次设计的过程中，我发现很多场景下一旦多一个抽象层次，事情会简单很多，无论是属性和方法的复用，还是相似类的统一管理，以及迭代过程中的增量开发，一旦引入层次，结构会清晰很多，工作量也能适当减少。

2. 类的分工与协作
   荣老师一直强调最基本的设计——输入、处理、输出的分离，这点我是从第二单元才开始实践的，初步感觉到了一些作用，但是后面两个单元基本上都不用自己设计输入输出了，倒是在学期中一次偶然的机会，帮高中同学搞了一点应用程序的开发，在这个过程中发现当程序既需要从文件读入基础数据，又需要从控制台（和 GUI）读入新增和修改数据，这时针对输入的抽象就显得尤为重要了。

   此外就是针对处理部分中的各个类，尽可能严格遵照“单一职能原则”，并且适当设计类之间的关联，让整体设计更加清晰。

3. 关于迭代与开闭原则
   我整个学期的架构比较稳定，只在第一单元进行了一次部分的重构。但是感觉开闭原则还需要更多的经验来验证，主要是前两个单元还没太整理好思路，后两个单元迭代的变化就比较小了，没什么重构的需求。整个课程学下来，“设计”的感觉确实是有些进步。

4. 设计先行
   这条暂时还大部分只存在于理论中，但是部分的实践也确实显得很有作用，从第一单元的划分表达式、拆分语法，到第二单元的流水线草图，再到后两个单元的 JML 和 UML，我能感受到一种设计逐渐与实现分开的过程，但是现在还是在以边实现边设计为主，还需要进一步的实践来积累经验吧。

总结自己在四个单元中测试思维的演进

主要是有了一个单一到多元、随机到针对的演进。虽然整个课程中我只搭了一个不太成功的评测机，最后的单元测试也没有全覆盖，但是对于测试的感受确实也有一些进步。

首先是测试方法，我从一开始只知道黑箱的、随机的测试，到后来逐渐掌握白箱测试、压力测试、回归测试等等。从多方面对代码进行测试，虽然测试总归是测不完全的，但是充分的测试确实能给我们的代码一个最基本的功能和性能的保障。

此外就是从纯随机到针对性数据，比如控制数据生成的范围，以及手动构造常规数据、边缘数据、异常数据等多方面测试。

此外就是掌握了基于设计而非实现的分离式测试，主要是针对第三单元的契约式设计，设计与实现相分离方便了实现于测试相分离，在测试端只需要面向需求做测试即可，不必担心针对实现进行测试的不全面和受限于经由实现对需求的二次理解。

此外就是测试可能还是与实现从思维上尽可能地分离会达到更好的效果，可以避免重复落入同一个思维误区。最彻底的就是由不同的人来分担这两项工作，但是在我们的课程环境下一般不太好实现，所以还是像荣老师说的那样，“自己雇佣自己”，尽可能让自己从另一个角度观察需求，从而进行更全面、更充分的测试。

总结自己的课程收获

从工具来说，掌握了 Java 语言、UML 图、JML 语言（主要还是它背后的契约设计吧）以及贯穿 OOpre，OO 甚至 OS 的 git。

更重要的是思维——设计的思维。OO 远远不只是讲面向对象编程本身，更不是“Java 语言程序设计”，而是重在“设计”。良好的架构可以减少工作量、获得更好的迭代体验，以及看起来更舒服的整体架构。如果没有一个良好的设计，最终写出来的就是纯纯的“屎山”，自己再也不想看一眼，迭代更是迭不了一点。设计的思想似乎很难完整表述，更多的是一种经验和感受吧。

此外就是测试的思路，从无到有、从随机到针对性，测试思维的演进也是一个极其宝贵的收获了。

另外就是收获了一段充实的大二下学期，传说中的 CO-OO-OS 也告一段落了，OO 课程的训练也算是一段宝贵的回忆了，认识了一些很优秀的同学，以及理论课的荣老师，让我在 OO 课上不仅学到了面向对象的设计思维，更是夯实了一些 C 语言基础（好神奇），可见“OO岂是如此不便之物”，只要积攒了足够的思维能力，OO 不一定是一切的解决方案，但是可以提供一个很好的思路。