OO第四次博客作业及总结

仲奕-ZC061007 2026-06-19 17:05:30

一、两阶类图

一阶类图要求在代码编写前完成，其核心价值在于强制我们在着手编码之前进行充分的架构思考。在我的作业中，设计一阶类图首先需要从需求描述中识别核心实体，图书馆系统的核心实体包括用户、图书、图书副本、各类地点以及系统总控等。其次需要确定类之间的关系，例如用户与图书副本之间存在持有关系，系统总控与各地点之间存在管理关系，图书与图书副本之间存在一对多的组合关系。最后还需要为每个核心类设计关键属性和方法，这一阶段不追求面面俱到，而是抓住每个类的核心职责，例如用户类需要关注其持有的图书列表、预约记录和信用分，图书副本需要记录其当前位置和历史移动轨迹。一阶类图的本质是需求到设计的第一次映射，它将描述性的自然语言需求转化为结构化的UML模型，为后续的代码实现提供了清晰的导航。

二阶类图则在代码实现完成后进行修订，其核心作用是保持设计与实现的一致性。在实际开发中，编码过程中难免会发现一阶设计的不合理之处，或因需求理解加深而产生架构调整，二阶类图正是用来记录这些调整的。我在二阶类图中主要将一阶中过于抽象的设计具体化，例如将地点接口细化为书架、借还处等具体类，补充一阶中遗漏的辅助类如信用分计算模块，并调整部分方法的签名使其与实际代码保持一致。二阶类图的价值在于它形成了一个可追溯的设计文档，当代码规模膨胀到一定程度时，直接阅读代码理解架构的成本很高，而维护良好的二阶类图可以帮助开发者快速把握系统全貌。

两阶类图的配合形成了“设计→实现→修正设计”的完整闭环，这种两阶段设计模式的价值首先体现在降低了设计失误的成本上，在一阶阶段发现架构问题，修改的成本远低于在代码完成后再重构；其次它提供了设计演进的记录，对比两阶类图可以清晰看到设计思路的演变过程；最重要的是它培养了设计驱动的开发习惯，让我们学会先想清楚怎么做，再动手做出来

二、架构设计与代码实现

在本单元中，UML类图与代码实现之间存在清晰而系统的追踪关系。从类的映射来看，UML中的每个类对应Java代码中的一个类，类名的完全一致性是追踪的基础；从属性的映射来看，UML类图中的属性对应Java类的成员变量，可见性和类型需要保持一致；从方法的映射来看，UML中的操作对应Java类的方法，方法名、返回值类型、参数列表的顺序和类型都需要一致

状态图与程序行为的对应也是本单元的重要实践。本单元要求为图书设计状态图，并用Trigger注解在代码中标注状态转移，这种机制确保了状态图不仅仅是画着好看的，而是与程序的实际行为建立了强绑定。我在实现中为图书副本定义了在书架、被借出、阅读中、预约处、借还处等状态，每个状态转移都对应一个业务操作，例如借阅方法会将状态从在书架转为被借出。类图与代码的追踪关系本质上解决了抽象设计如何落地为具体实现的问题

三、大模型辅助正向建模

我认为大模型在架构设计中最合适的角色是辅助者而非设计者。核心设计决策如系统边界划分、核心实体定义、关键交互流程仍需由开发者做出，大模型可以在需求到模型的初步转换、设计细节的快速补充、设计一致性的初步检查以及设计文档的生成等方面提供辅助。

四、架构设计思维的演进

在最初几次作业中我的代码几乎是所有功能耦合在一个类中，扩展性几乎为零。痛苦的迭代经历让我意识到了架构设计的重要性，在后续重构中我采用了经典的解析层、处理层、输出层架构，这个单元让我第一次体会到了好的架构让迭代事半功倍的道理。第二单元引入了多线程编程，任务是模拟多部电梯的调度系统，这个单元最大的挑战不是多线程语法本身，而是如何设计线程间的协作机制。我最初的设计采用了简单的请求队列加电梯线程模式，但很快就发现当电梯需要检修或改造时简单的队列模型无法处理请求的重新分配，后面又进行了重构。这个单元让我认识到架构设计不仅是类的组织，更是运行时行为的规划，良好的多线程架构应该明确哪些数据是共享的、线程间的同步点在哪里、异常情况如何处理。

第三单元是JML规格化开发，要求我们严格依据给定的规格实现社交网络系统，这个单元的特殊之处在于架构已经由规格隐式定义，我们需要做的是在规格约束下做出合理的设计决策。这个单元让我意识到即使是规格驱动的开发，架构设计思维依然重要，好的设计是在满足规格的前提下追求更优的效率和更好的代码可读性。第四单元则通过两阶类图的机制，强制我们实践了设计优先的开发模式，与前三个单元不同，本单元要求我们在写代码之前提交一阶类图。