OO第四单元博客 && 课程总结

第四单元正向建模与开发

• 第四单元基于UML进行正向建模与开发。通过将自己的架构设计用图的方式进行呈现，我们可以清晰地呈现自己的思路，对可能存在的疏漏进行提前修复，在代码编写的过程中也有了极为可靠的参考，大大提高了开发效率。

• 在绘制UML图的过程中，我习惯于从真实情景的角度出发进行架构设计。例如，在本单元设计图书馆管理系统时，我会结合现实情境进行考察：为了统一处理各类输入指令，我首先需要一个总体的信息调度处，进行指令的输入与分发，因此新建Library类；不同类型的指令，应该交由图书馆的不同管理处处理，如借书找借书处，预约找预约处，捐献找捐献处，因此新建BorrowOffice, AppointOffice, DonateOffice类；借书处进行具体的借书、还书操作，需要得到所有借书人的信息，因此又新建Student类以及全局的StudentMap类作为全局的用户信息表，并设置为BorrowOffice类的属性，等等。这样的设计思想有利于UML图的构建，各个类之间的信息交互也更加直观。

第四单元架构设计总结

• UML类图如下：

  

从图中可以看出，类的数量较多，联系也较为复杂。这主要是满足不同需求时需要获取的信息类型不同，需要构建的容器也不同。为了避免容器套容器等情况的出现，我将不同类型的信息都封装为了单独的类，好处是单一类内代码较为简洁，处理直观；缺点是类之间的交互较多，没有很好地满足高内聚低耦合的要求，还有改进的空间。

• 由于是先画UML图再编写代码，在思路调整时对UML图也进行相应调整，因此我认为我最终代码设计与UML模型设计之间的一致性还是较高的。当然，由于评测采用的是必要性检测，在某些地方出现遗漏也是有可能的，值得进一步打磨。

总体架构思维演进

• 第一单元我第一次接触到1000行以上的“大型”（当然是对我而言）项目，这时架构设计对我来说还是较为困难的。因此我主要参考了学长学姐的架构，在借鉴中逐渐领会设计思想。我记得第一单元中Mono和Poly的设计令我感觉十分巧妙，将不同类型的表达式化简工作统一为了一种形式。很难说现在的我是否能够在没有参考的情况下设计出这样的架构，但这一单元的学习与实践对于我的架构设计能力毫无疑问是提升巨大的。

• 第二单元确实与学长学姐们所说的一样，极具难度。虽然我的困扰大部分发生在同步控制上，但架构设计的耗时与思考量也是极大的。我当时还没有很好的架构设计习惯，仍然保持着面向过程程序设计的思想，将主要精力聚焦于某一个方法的实现上，而没有从总体上对架构进行细致设计，总是写到一半发现无法处理了，再新建一个类进行数据的封装与处理，然后接着写下去。这样的代码缺乏整体性，有些隐蔽的bug在进行大量测试之前不容易发现。第一次进行细致的架构设计是第二单元第三次作业，双轿厢电梯的引入给我以前边写边处理的方式造成了极大的困难，因此我先画了一个整体的架构图，分析了信息交互的路径和需要添加的方法，给我后续编写代码的过程带来了极大的方便。这也是我第一次真正体会到架构设计的好处。

• 第三单元聚焦于JML。架构已经给定，基本上没有什么设计空间，故在此略去。

• 第四单元留给我们的设计空间是最大的。具体的设计思路在上面两个版块已经进行了详细阐述，故在此就不再赘述。但我确实已经习惯了先设计架构再编写代码的模式，编写较为大型的项目时速度更快，也更加得心应手。四个单元的历练，带给我的提升是显而易见的。

测试思维的演进

• 有一说一，或许是有同学搭建的评测机的缘故，我在构造数据点以对程序进行测试的方面并没有耗费很多精力。说到这里，必须感谢gpf, zx以及cxc同学，给我白嫖评测机（bushi 。说到自己的努力，大部分集中在第一单元写了一个自动对拍器，以及第三单元对规定的方法编写JUnit。不过对拍器实在没有什么技术含量，JUnit的部分又在第三单元总结中有过细致阐述，故在此不再赘述。说来惭愧，很难分析出自己四个单元测试思维有什么演进。或许使用评测机进行debug更加熟练了（？

课程收获

• 知识层面的收获就不多说了，我想教学大纲比我分析得更清楚。从更高层次来说，我想面向对象带给我的更多是“代码能力”这一听起来很笼统的能力的提高。我现在依然会想起大一时完成数据结构大作业，写出400行的代码就觉得实在是超大工程，但现在我一不注意，可能一个类就超过了400行。虽然没有固定的线性关系，但代码行数增多通常代表着项目规模的增大，而能够编写更大的项目，面向对象的思想在其中起到了很大的作用。在面向过程的程序编写过程中，我们的目光聚焦于过程之上，但随着过程分支的增多，复杂度的提高，保持整体的协调性就更加困难。很难想象一个函数如果超过了600行，对它进行错误排查是一件多么麻烦的事情。但面向对象的思想将我们从具体的过程中抽离了出来，分析一个个形式上独立的对象，对每个不同对象进行独立的代码编写自然更为方便，最后再从更高层次上进行信息的交互，就将各式各样的对象串联起了一个整体，编写大型项目时自然更加轻松。

对课程的建议

• 总体来说，OO课程的设计我是比较满意的，任务繁重而又不至于太过度，通过实践也让我的知识得到了很好的巩固。不过相较于作业，感觉理论课的内容略显鸡肋。抽象概念有点太多了，不结合代码的话很难知道表达的具体是什么，同学们的参与度也不高。希望对于重点概念能给出代码示例分析，就我的观察，同学们是更喜欢看代码的，课上的代码分析也有利于避免课下完成作业的试错。另外OO上机略显幽默，如果目的在于给同学们架构提示的话不如将任务移至课下，早起上机却需要面对同学的频繁交流，以及可以直接用copilot补全的填空，感觉有点难蚌。当然，这可能是课程组不给我们增加负担的良苦用心，但是要坚持上机的形式的话不如正式一点？如果考虑到课程设计的要求的话感觉不如取消实验，直接将实验预习题纳入评分（。

• 对题目的建议见助教报名问卷。希望老师能看看~~