面向对象设计与构造OO：Unit4-图书馆系统

0 前言

第四单元的内容聚焦在以一个图书馆管理系统为背景，锻炼对程序架构的设计和抽象能力，以及UML建模能力（包括类图、状态图和顺序图）。

本文将分别介绍三次迭代作业，每部分包括需求说明、项目结构、架构设计等。其次将总结 2025 OO 课程的全部内容，涉及四个单元中架构设计思维和测试思维的演进。最后总结心得体会。

1 第十三次作业

1.1 需求说明

第一次迭代需要模拟一个小型的图书管理系统，完成图书馆所支持的相关业务。书籍可以存在于四个位置：书架、预约处、借还处和用户。支持的指令包括借阅、还书、预约、取书、查询、开闭馆。

1.2 项目结构

1.2.1 UML 类图

1.3 架构设计

1.3.1 正向建模与开发

初步尝试“完全正向建模”，即先画 UML 类图，把属性和方法都确定了，再无脑填写代码。发现不符合实际。因为属性的数据结构的选取、方法之间的互动都需要慎重思考并在实践中尝试，直接写出最终的 UML 类图有点像纸上谈兵。

不过，先在 UML 类图中确定好类，以及它们之间的关系，而不管属性和方法，是可以做到的，这是一个全局的视角；之后在代码中去补充属性和方法，这是个局部的视角；最后完善 UML 类图。这种方法是可行的，并且在之后的作业中我也沿用了，效率很高。总而言之，类图从全局视角确定了主体框架，代码从局部视角确定了具体实现。

1.3.1 总体架构

官方包提供了 main 函数的输入解析示例代码，本着“君子善假于物也”，直接用了！解析好指令后，传递给图书馆类，图书馆内又有书架、预约处、借还处等部门，将 book 的实体在他们之间互相传递即可。

起初，我将书架、预约处、借还处三个部门都抽象成“Office”，实现一个继承关系，父类确定了 book 容器的具体形式。不过后来发现没必要，因为无法用同一种容器兼容到三个部门。

• 书架：摆放的书籍是严格有序的，因为这样方便取出想要的书。使用 HashMap<LibraryBookIsbn, LinkedList<Book>> 可以实现题目要求。
• 预约处：预约处包含待取走的书，以及过期了需要回收的书。待取走的书每本都关联了一个用户，因此使用 HashMap<String, Book> 实现学号和书籍映射；过期了的书没有明确关系，LinkedList<Book> 用链表串起来就好。
• 借还处：这里放着用户还回来的书，还未被整理。因此也用链表 LinkedList<Book> 串起来就好。

除此之外，实现了一个数据库，里面包含全局书籍 ISBN 到实体的映射，以及用户学号到用户实体的映射，方便查询。

2 第十四次作业

2.1 需求说明

在之前的基础上，新增书籍部门热门书架、阅览室，新增指令阅读、归还。

2.2 项目结构

2.2.1 UML 类图

2.2.2 UML 状态图

2.3 架构设计

将热门书架和阅览室两个部门加入图书馆即可。

3 第十五次作业

3.1 需求说明

在之前的基础上，引入用户信用分系统，对用户的行为作进一步限制，新增图书馆借阅期限。

3.2 项目结构

3.2.1 UML 类图

3.2.2 UML 状态图

3.2.3 UML 顺序图

3.3 架构设计

3.3.1 大模型辅助

虽然作业没有使用大模型，但上机实验体验过，我的感想是，大模型适合于完成黑盒，即确定的输入和预期输出，而不去动他内部的逻辑了。这样可以达成最高效，不浪费时间。因为读懂大模型写的代码还是有些艰难的（）。具体例子可以回溯第三单元实现 HashLinkedList，我将需求直接告诉大模型，写出来之后我也不去管代码内部实现了，因为直接可以用。包括 BFS 的实现，我也直接交给大模型了，相当于在我的系统中拼接了一块其他商家的积木。

3.3.2 UML 模型之间的追踪关系

这次作业集齐了三种 UML 模型，类图是对总体结构的把控，状态图是对图书馆行为的高度抽象，顺序图是对代码方法之间组织的总结。

在这单元实现的过程中，类图对写代码有一定的指导作用；而状态图是在写完代码之后再抽象出来的，给我一种直观的回顾；顺序图更是起到了零个作用，原因是顺序图是方法之间的调用关系，是在太细节太局部了，我感觉适合于写好代码的开发者向其他人介绍代码调用关系所用，就像 OS 指导书内的函数调用关系顺序图一样。

4 课程总结

4.1 架构设计思维的演进

第一单元，我草草阅读训练代码和实验代码，直接开始动手，殊不知对递归下降理解止步于浅层，导致架构混乱，类的设计想一出是一出，在第二次作业就不得已经历了大重构。

第二单元，我反复阅读学长学姐博客，对需求有了全局的把握，再开始慢慢在尝试中学习多线程。第一次迭代顺利完成，归功于之前的广泛阅读博客；第二次迭代扑街，因为对多线程机制研究不深入；第三次作业及时补救，结果良好。

第三单元，由于给出了 JML 规格，直接无脑上手实现即可。体会到了契约式编程的好处。

第四单元，学会正向建模，没有重构，没有很大的改动。

4.2 测试思维的演进

第一单元，不会测试，甚至认为测试是没必要的，最终强测不太好看。

第二单元，开始写自动正确性检验评测机，对找 bug 有一些帮助。

第三单元，Junit 和对拍评测机双管齐下。由于第二单元已经写（应该算是）了本课程难度最高的评测机，这个单元评测机很轻松，因为只需要随机生成指令，对拍即可，无需正确性判断逻辑。在捣鼓评测机的过程中也尝试出了增强数据的方法，最终测出了强测都没测出的点。

第四单元，没有特别测试，因为架构较简单。

5 心得体会

该怎么说出口，最终来到 OO 课的尾声啦！

在大一期间就有所听闻的大名鼎鼎的 OO，确实是名副其实。从 pre 课程的初识 java，到正课的上机实验、中测强测互测、研讨课、博客周、宣传组。OO 给了我其他课程都替代不了的特别的回忆。当忙碌于表达式展开与电梯调度时，有时也会因为强测爆零在心中骂了 OO 无数次，但我确实成长了很多，学的很开心，收获了一场特别的体验！

OO 让我对写代码有了新的认识，原来写代码也可以这么优雅。回想起大一上程序设计课程用着简陋的 Dev C++ 写着丑陋的代码；大一下数据结构课程用 vscode 写着变量命名非常灾难的超长屎山。OO 让我初步有了“专业范儿”，也对程序这个抽象的东西有了多一层的维度认识！

如果在 CO 和 OS 课中收获的是揭开计算机底层原理神秘面纱的求知感，那么在 OO 中收获的是将想法付诸现实，看着复杂系统稳定运行的快感。Java 是天才的语言，面向对象是天才的理念。

我想我不会忘记。通宵尝试解开死锁无果的那个晚上；评测机帮朋友们找到 bug 的喜悦；在评测出故障的互测房中解锁 （6/7）刀人战绩的误打误撞；你在强测中获得了 0 分的惆怅；研讨课上大胆走上讲台的我；博客周努力码字努力画图入驻 CSDN 的主包；在宣传组和好伙伴们协商办大事收获破纪录阅读量的惊喜；早八上机后和室友一起去吃麦麦……点点滴滴，给我的大二下学期增添了不少色彩。（对比大二上 CO 上机结束后失落心灰意冷之孤苦伶仃夜路哎哎）

希望我与 OO 的缘分不止如此。不管如何，先说一句感谢，再说一句再见！