2024年春 BUAA OOU4博客作业 & OO课程总结博客

零、前言

十六周，总是昏天黑地，偶尔遍体鳞伤，但还是“爱惨了”OO。

一、单元实践总结

在第三单元中，我隐约感受到了正向设计在工程开发中的应用。没有人会先动手后动脑，但有设计也需要讲究技巧。

也许在前两单元中，我们尝试过以伪代码、流程图等形式梳理思路、辅助评价架构。但是，设计不仅仅是一个人在草纸上的乱涂乱画；它应该清晰明了，无二义性是它区分于自然语言的最大特点；它应该清晰准确，能合理描述代码实现的细节；它应该形式简明，便于阅读者提取信息，更便于修改迭代。

所以经历了U1U2的自主摸索与U3那漫长的设计感悟，U4便是我们实践正向设计的机会。

所谓“正向建模”，就是设计先于coding 。UML专为设计而生，较为正式、广为接受。在类图、流程图、顺序图的绘制中，我们能清晰的认知架构特点，把握系统结构。当我们需要进行可扩展设计、可读性设计、性能设计时，它们也为我们的修改甚至重构提供了依据。

在Hw13中，我首先划分图书馆中各种数据的存储区域，之后根据这些区域，编写业务代码，并在必要时建立模块间的通信方法。而对于业务代码的实现，也做到了层层封装，逻辑分离。

类图始终是我掌握结构的依据 ，而我也根据类图思考方法的调用关系，层次设计。

而状态图与顺序图则更多在我完成初步设计后进行检查时发挥作用，我借此找出设计中存在的漏洞。

而进行了这样的设计之后，在架构上的问题得到了很好的避免~（虽然小bug依然不断）

二、本单元架构设计

如上面的类图所示。

图书馆中的中心部门为MyLibrary，该部门负责解析请求并分发给所有的分部。我设计的分部如下：

• CirculationDesk:借还处，处理借书流程。该类模拟借还处的行为，提供借书相关方法和借还处的数据结构。

• Appointments:预约处，与借还处很类似。也提供相应方法与数据结构。

• Bookshelf:书架，只需模拟书架行为。

• Database:设计该类的核心思想是统一记录公共数据，便于图书馆中所有类共享。该类存储所有图书馆的内部数据，包括用户借书信息、捐书信息、信用分信息。

• DriftCorner:图书漂流角，与书架同构。

• 另外的两个类都是为了便于存储信息新建的类，只是信息的集合体，并未在结构中发挥作用。（而且随着官方包在每次作业中不断完善，其实不用也可）。

书籍可能出现在书架、借还处、预约处、漂流角等。我们需要相应的数据结构来模拟书籍位置的变化。同时对于每种请求，可用流程图检查各方法相互调用的作用效果。同时，通过一个共享的database统一记录、查询数据。

而在历次的迭代之中，UML也随之变化。架构最初的建立由UML指导，但之后的改动会反映在UML上。此时也可以分辨出修改的合理性。

三、架构设计思维的演进

U1中，虽然对于递归下降的掌握还不错。但是在历次迭代中没有灵活调整，自身考虑和学习参考都不够多，实现的较为简略，所以到后来程序出现了一些递归深度过大、运行过慢等问题。

这一单元中，我在设计方面的考量主要着眼于减少bug,并摸索出了一些小窍门。但对架构的考量仍然比较少。

在U2中，我吸取U1教训，先设计再实现。采用示意图的方式描述架构。设计的意识是到位了，但规范性还不够。首先是示意图的方式不够清晰，有时候我并不能依靠示意图完全记忆起实现细节，仍然不时需要回忆。另外，这种方式对于死锁检测也无法提供依据。仍记得hw7时设计出现了问题，会引发死锁。而这个bug在实现完成后，测试阶段才被发现。当时也来不及重构，只能以比较丑陋的方法敷衍了事。

但总的来说，U2是我在架构设计中进步最大的单元。

在我还在回味前两单元的经历时，U3的到来刷新了我对设计的认识。在我看来，JML既有契约、也有设计。同时实现了减少bug,理清架构的功能。我相信，JML的提出者所具有的理念，在当时一定是超前，且在今天也仍然是伟大的。即使JML不便于以评测形式考核，但其思想十分值得学习。

我默默品味JML代码，觉得设计的思想内核就应该类似于这样。

摩拳擦掌的迎来了U4。代码未动，架构先行。对于业务代码的实现，尽可能的合理封装分层。对于在整个学习过程中品悟到的一些方法。如读写分离、禁止逆层次化等，也都在实践中有所运用。

应该说，U4是比较完美的一个单元。学完U4的我也是一个有所收获的人。

四、测试思维的演进

在U1U2两个单元，我都与其他同学合作进行评测机搭建。追求全面的黑盒测试。依靠最够多的测试数据来保证正确性。

但进入U3U4后，我越来越觉得，仅靠黑盒测试是远远不够的。毕竟永远不可能保证测试的数据涵盖了所有情况。程序的Bug千奇百怪，是黑盒测试难以排除的。

在荣老师的鼓励下，我与我的好朋友 ytgg 每周进行代码互查。事实证明我的互查工作做的相当不错，yt 就有点逊了。

代码的准确性，最终还是要回归架构设计的合理与清晰；代码准确性的保证，最终还是依靠与白盒测试。测试的尽头，大概是阅读代码，进行静态分支覆盖吧（笑）。

五、课程收获

回看oop时期自己写的代码，我在层次化设计方面的能力必然得到了极大的提升。

而除去课程相关的能力与兴趣培养外。OO这门课的学习经历也留给了我很多可贵的东西。在不断的设计和研究中，我发现我也能做到一些事情，也能总结出一些有意思的东西出来分享给大家。与很great的朋友们探讨分享，帮助他人，体验都超级棒！

如果说学完祭祖以后我想的是“总算撑过来了”，那现在我想的是“就这样，再出发吧！”