OO第四单元博客总结

[付耀-24371170]

一 正向建模与开发

以前写代码，遇到需求直接上手敲，写到哪里算哪里，这导致类与类之间的关系往往是“面条式”纠缠在一起的。而本单元引入了两阶类图（一阶设计，二阶重构）的机制：

• 编写第一行 Java 代码前，我会绘制了一阶类图。一阶类图不需要事无巨细地包含所有 getter/setter，它的核心作用是划分职责边界。例如，我决定了 LibraryManager 与 BookShelf 等部门是“组合（Composite）”关系（同生共死），而与 User 是普通“关联”关系。这种强迫性的前置思考，让我避免了在开发中途发生结构性崩塌。
• 代码在实现过程中必然会遇到原设计未考虑的细节（如图书副本的轨迹追溯需要新增 LibraryTrace 实体）。二阶类图允许我们在代码完成后对模型进行修正。这让我深刻认识到：正向建模绝不是瀑布流式的死板教条，而是与代码相互印证、持续演进的动态过程

  二 架构设计与 UML 模型的追踪追踪关系

  在图书馆系统中，我的最终架构由以下几个核心模块构成，且与 UML 模型保持了极强的追踪关系：
• LibraryManager。在类图中它聚合了所有的部门，并在代码中承载了时间线推进（openLibrary, closeLibrary）以及请求分发（handleRequest）的全局统筹功能。
• BookShelf, BorrowAndReturnOffice, AppointmentOffice。在 UML 中，它们都持有 Set。在代码层面，我严格遵守了这一点，确保所有图书物理位置的转移本质上都是在这个三个 Set 中移入移出，保证了守恒定律。
• 借阅规则极为复杂（限制 A/B/C 类书的不同额度）。在 UML 设计时，我专门剥离出了一个 BorrowLimit 工具类。在代码中，这使得 LibraryManager 的业务逻辑极度干净，将易变的“审查规则”完全解耦。
• 在提交最终 mdj 文件时，我遭遇了评测机的结构解析错误。这让我意识到 UML 不仅仅是“给人看的图”，它底层的 JSON 结构（如必须存在的 _parent 字段，以及必须分离的 attributes 和 operations 数组）体现了极其严谨的元模型（Meta-model）标准。为此，我还专门编写了 Python 脚本对底层结构进行重组重构，这也是模型与代码底层追踪的有趣插曲。

  三 大模型在复杂架构设计中的引导体验

• 在本单元，我尝试引导大模型（LLM）协助我完成从需求到 UML 架构的跨越。如果把长达几千字的图书馆规则直接喂给大模型，它生成的架构往往是混乱且缺乏层次的。
• 大模型往往倾向于生成“贫血模型”（即所有逻辑全堆在 Manager 里，其他类只有数据）。作为架构师，我必须强行干预，要求大模型把“判断逾期”的逻辑下放到 BookCopy 类中，贯彻“高内聚低耦合”的思想。
• 同时，如果让大模型直接生成类图，会遭遇解析错误等困难。通过添加skill等方式可以得到缓解。

  四 四个单元的架构设计思维演进

  回首这一学期，我的架构设计思维经历了四次蜕变：
• 第一单元（多项式导数）：从“面向过程”到“对象抽象”。我学会了抛弃 C 语言的 switch-case 字符串解析，转而使用递归下降算法，将每一种运算抽象为一棵表达树上的节点。
• 第二单元（多线程电梯）：从“单体运作”到“解耦协同”。面对并发的数据竞争，我懂得了什么是职责分离。我设计了“调度器（聪明人）统筹全局，电梯（老实人）只管运行”的架构，利用物理锁保证安全，高层预判打破死锁。
• 第三单元（JML 网络）：从“自由发挥”到“契约精神”。我开始明白，优秀的架构需要在“业务契约（JML）”与“底层性能（HashMap 降维、动态维护）”之间寻找完美的平衡点。
• 第四单元（UML 图书馆）：从“边写边想”到“顶层规划”。我最终掌握了上帝视角，学会了用 UML 鸟瞰整个系统，将大系统拆解为小模块，让代码在可控的图纸上生根发芽。

  五 四个单元的测试思维演进

• 第一单元（黑盒测试）：主要依靠 Python 编写评测机，利用 sympy 库进行海量随机数据的输出比对（对拍）。
• 第二单元（时序追踪）：并发程序无法轻易复现 Bug，我学会了基于 TimableOutput 打印时间戳，并利用“极限边界构造法”去定向复现 F2 楼层的死锁问题。
• 第三单元（单元测试）：深入掌握了 JUnit。面对 JML 的 pure 属性，我独创了“双重快照/影分身对比法”，严格验证方法是否发生了越权修改。
• 第四单元（状态机覆盖）：图书馆系统本质是一个庞大的状态机。我在测试时不再局限于单点逻辑，而是构造完整的生命周期闭环（例如：预约 -> 整理派送 -> 过期未取 -> 再次入库），关注系统状态的流转正确性。

  六 体验与感受

  OO课程深深在我脑海中植入了“工程化”这三个字。它让我知道，当代码规模从几百行膨胀到数千行时，维持系统不崩溃的，是低耦合的层次设计；在深更半夜 Debug 时拯救我的，是严谨全面的自动化测试脚本；而在接手复杂业务时，指引我破局的，是清晰的正向建模类图。
  感谢 OO 课程组这一路的陪伴、指导与精心设计的每一次迭代。带着这套从“工匠”走向“建筑师”的思维体系，我已准备好迎接未来的星辰大海。