OO Unit4 博客总结 && 课程总结

沈钡-24373462 2026-06-20 01:52:57

面向对象设计与构造——第四单元及课程技术总结

引言

本技术博客围绕2026年面向对象设计与构造课程的第四单元（图书馆管理系统）三次作业及全课程内容，进行全面的回顾与总结。在第四单元中，我们首次实践了正向建模与开发，通过两阶UML类图指导系统架构设计，并辅以状态图和顺序图描述对象行为与对象间交互；同时，大语言模型在辅助设计、代码生成与错误排查中发挥了重要作用。以下将从六个维度展开：正向建模实践、架构设计与追踪关系、大模型辅助设计体验、架构思维演进、测试思维演进以及课程总体收获。

一、正向建模与开发实践：两阶类图的核心作用

第四单元的核心训练目标是正向建模——即在编写代码之前，先通过UML类图完成架构设计，再依据设计进行实现。这与前三个单元“先写代码后画图”的逆向工程形成鲜明对比。

在第十四次、第十五次作业中，我们实践了两阶类图的正向建模流程。

1.1 一阶类图：架构的蓝图与契约

一阶类图在代码编写前完成，其核心作用体现在三个方面：

（1）确立核心抽象与职责边界

绘制一阶类图时，必须首先识别系统中的核心实体及其关系。以图书馆管理系统为例，我们需要抽象出 LibraryManager（管理核心）、Book 与 BookCopy（图书与副本）、User（用户）、各种地点类（Bookshelf、AppointmentOffice、BorrowReturnOffice、ReadingRoom）等。这个过程迫使我们思考每个类应当承担的职责——例如，借阅限制逻辑应该放在 User 还是 LibraryManager 中？图书移动轨迹是 BookCopy 的属性还是独立管理？

（2）强制分离关注点

一阶类图不允许我们一开始就陷入实现细节。例如，我们在一阶图中只定义了 LibraryManager 具有 borrowBook、returnBook 等方法，但不关心内部如何实现。这种抽象层次的强制提升，帮助我们建立了更清晰的模块边界。

（3）预判迭代需求

在第十五次作业中，新增了信用分系统、借阅期限和续订功能。由于一阶类图已经建立了良好的基础架构，我们只需在一阶图基础上增加 CreditManager 类和 BorrowRecord 类，并在相关类中补充 credit 属性和 renew 方法即可，而不需要对整体架构推倒重来。

1.2 二阶类图：从设计到实现的桥梁

二阶类图在代码完成后进行修正，其核心作用包括：

（1）详细化设计契约

一阶类图中，方法往往只有名称而无参数和返回值。二阶类图要求我们补充完整的参数列表和返回类型——例如 borrowBook 的参数从无到有，变为 (String studentId, ISBN isbn, LocalDate date): BookCopy。这使得类图从“示意”升级为“精确契约”，可以直接指导编码和测试。

（2）检验设计与实现的一致性

评测系统对二阶类图执行R1-R5的全面检查，包括属性名、方法名、可见性、返回值类型的匹配。这一过程揭示了许多设计偏差——例如我们在类图中遗漏了 Main 类的某些辅助方法，或者方法参数顺序与代码不一致。修正这些偏差的过程，本质上是在验证我们的实现是否忠实于原始设计。

（3）管理架构演化

从一阶到二阶，类图的变化（如类名从 Library 改为 LibraryManager、新增 CreditManager 和 BorrowRecord）被记录在重构说明中。这种演化追踪帮助我们理解设计决策的变更原因，也为后续维护提供了历史依据。

关键体会：两阶类图的设计并非“先画图再写代码”那么简单，而是一个螺旋上升的过程——设计指导实现，实现反馈修正设计，最终两者趋于一致。评测系统的相似度检查（要求两阶类图相似度不低于60%）正是为了确保我们没有在一阶时“敷衍画图”而在二阶时“彻底重来”。

二、架构设计与追踪关系分析

2.1 整体架构设计

本单元作业采用了分层架构 + 领域模型的设计思路：

核心管理层：LibraryManager 作为门面，负责协调所有操作（开馆、闭馆、借阅、归还、预约、取书、阅读、评分、续订、信用查询），持有所有地点对象和用户、图书的集合。

领域模型层：

图书域：ISBN（身份标识）、Book（同ISBN的聚合根，管理副本集合）、BookCopy（单个副本，记录状态和移动轨迹）
用户域：User（管理借阅记录、预约记录、信用分、阅读状态）、BorrowRecord（单次借阅的期限和续订）、OrderRecord（单次预约的过期状态）
信用域：CreditManager（集中管理所有用户的信用分，支持查询和调整）

地点管理层：Bookshelf、TreasuredBookshelf、AppointmentOffice、BorrowReturnOffice、ReadingRoom，各自管理所在位置的图书集合，提供添加、移除、查询功能。

辅助层：Arranger（整理策略）、BorrowLimit（借阅限制检查）、Grader（评分计算）、MoveInfo和MoveTrace（数据传输对象）。

2.2 UML模型与代码的追踪关系

正向建模的核心价值在于保持设计模型与实现代码的可追踪性。以下是几个关键的追踪关系实例：

追踪维度	UML模型	Java代码	一致性检查
类名	`LibraryManager`	`public class LibraryManager`	名称完全匹配
属性	`bookshelf: Bookshelf`	`private Bookshelf bookshelf;`	名称、类型、可见性一致
方法	`borrowBook(studentId, isbn, date): BookCopy`	`public BookCopy borrowBook(String, ISBN, LocalDate)`	参数顺序、返回值类型一致
关联关系	`LibraryManager` 持有 `AppointmentOffice`	`private AppointmentOffice appointmentOffice;`	属性类型体现关联
枚举	`Location { BOOKSHELF, ... }`	`public enum Location { BOOKSHELF, ... }`	枚举项一一对应
状态图Trigger	`@Trigger(from="bs", to="user")`	`@Trigger(from="bs", to="user") public void borrow()`	状态名称和方法名匹配
顺序图消息	`orderNewBook: User → LibraryManager`	`@SendMessage(from="User", to="LibraryManager") public void orderNewBook()`	消息名和方法名一致

追踪关系的实践意义：

变更影响分析：当需要修改一个类的方法签名时，可以通过追踪关系快速定位到类图中需要同步更新的部分，以及代码中所有调用该方法的地方。
逆向验证：评测系统的R2-R5检查实际上是在验证“我们最终写的代码是否还是当初设计的样子”。如果偏离过大，说明要么设计不合理，要么实现时丢失了架构约束。
知识传递：类图作为文档，可以帮助其他开发者快速理解系统架构，而不需要通读所有代码。

三、大模型辅助正向建模的体验与引导策略

在本次作业中，我大量使用了大语言模型来辅助完成架构设计和代码实现。以下是基于这一体验总结的有效引导策略：

3.1 明确约束与规范

大模型在开放场景中容易产生幻觉，因此必须在一开始就明确所有硬性约束：

评测规则：R1-R5的检查项、关键词覆盖率要求、相似度检查标准。我会直接将指导书中的评测标准粘贴给模型，让它理解“什么是对的”。
文件格式：.mdj 文件的正确结构（ownedElements而非children、Model的name字段必须为"Model"、represents必须使用"class.XXX"格式等）。这些细节曾多次导致解析失败，但一旦明确告知，模型就能稳定输出。
代码规范：单方法不超过60行、使用官方包的具体类名和方法签名。

3.2 分阶段推进，逐步细化

正向建模本身就是一个逐步细化的过程，这与大模型的能力边界高度契合：

第一阶段（一阶类图）：只需提供类名、属性名、方法名（无参数细节），重点是覆盖关键词和核心实体。模型在这一阶段可以快速生成架构草图。
第二阶段（二阶类图+代码）：逐步补充方法参数、返回值类型、可见性，并确保类图与代码的一致性。我会将评测机的错误信息直接反馈给模型，让它针对性修正。

3.3 提供反馈迭代修正

大模型最强的能力之一是基于反馈快速修正。在调试顺序图消息路径时，评测机反复提示“起始消息不存在”，我将错误信息直接提供给模型，模型能够分析出问题在于represents格式、predecessor/successor字段的写法等，并逐次调整直到通过。

有效的反馈方式：

粘贴完整的评测输出（而非仅描述“出错了”）
提供期望输出与实际输出的对比（如stdout vs myout）
明确指出哪一部分需要修改（如“顺序图片段”）

3.4 人保持架构决策权，模型负责细化与检查

大模型适合完成机械性、规则明确的任务——例如按照规则生成类图的JSON结构、检查方法签名是否匹配、生成符合规范的@Trigger注解。但核心的抽象设计决策——例如将信用管理独立为CreditManager还是放在User中、借阅限制应该由哪个类负责——仍应由人类完成。

在实践中，我会先自己画出架构草图（哪些类、什么关系），然后让模型帮我补充细节、检查一致性、生成规范文件。这种人机协作模式既发挥了人类的抽象思维能力，又利用了大模型对规则和细节的精确处理能力。

3.5 引导大模型完成复杂架构设计的总结

提供完整上下文：指导书、官方包API、评测规则缺一不可。
设定明确边界：告知模型哪些可以自由发挥（如整理策略），哪些必须严格遵守（如输出格式）。
迭代式推进：先粗后细，每步验证，及时反馈。
利用模型的记忆能力：在同一对话中持续修正，模型能够记住之前的错误并避免重犯。
保留人工决策：架构的核心抽象应由人完成，模型是高效的执行者和检查者。

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

回顾整个2026OO课程，我的架构设计思维经历了从“能跑就行”到“设计先行”的显著转变。

4.1 第一单元：表达式解析——面向过程的遗留

第一单元的核心任务是表达式解析与化简。当时的我虽然使用了多个类（Main、Solver、Expr、Polynomial、Term），但本质上仍然是面向过程的思维——数据在类之间流转，类是“函数包”而非真正的对象。Expr类的解析方法长达数百行，圈复杂度爆表，体现了典型的“上帝类”问题。

核心问题：我关注的是“怎么解析字符串”，而不是“如何用对象协作表达语义”。Polynomial和Term虽然封装了数据，但行为逻辑全在Expr中，缺乏真正的职责分配。