一、四步建模法

一张类图从来不是"想出来的"，而是一步步推出来的。四个步骤，顺序不能乱：

为什么顺序不能乱：先想"谁"、再想"它有什么"、再想"它会什么"、最后想"它们怎么连"。反过来（先定关系）会陷入"这两个类该不该连"的死循环，因为你还不知道它们各自是什么。

二、第一步：找对象——从"名词"里挑候选

这是最关键也最容易做过头的一步。方法很朴素：

把需求描述里的名词（以及名词短语）圈出来，它们就是"类的候选名单"。

例（一句话需求）：

"读者拿着借书证到图书馆借一本图书，管理员登记一条借阅记录。"

圈出的名词：读者、借书证、图书馆、图书、管理员、借阅记录。

候选名单有了，但还不能全要——要过一遍筛子：

筛完的结果：读者、图书馆、图书、借阅记录（4 个类）。

永远问一句："这个类真的需要吗？" 多一个类，就多一份要维护的东西；少一个类，就会出现"某个类什么都管"的怪物。这一步的判断力，就是设计经验的核心。

三、第二、三步：定属性、定行为

定属性——问"它自己要知道什么"：

定行为——判据只有一条（9.2.2 讲过）：

"这件事主要是在改谁的数据？就写在谁身上。"

注意"读者.借书"这件事：读者发起借书，但真正改状态的是图书。所以 Reader 那边是个"请求"（Reader::borrow(Book*)），它内部去调 book->borrow()。"发起"和"执行"经常不在同一个类上——这是建模时最要细心的一处。

四、第四步：定关系——三条快问

对着每两个类，问这三句：

本例走一遍：

图书馆 ◆—— * 图书        （图书馆没了，它的藏书也就没了 → 组合）
图书馆 ◆—— * 借阅记录    （同上 → 组合）
读者 —— * 借阅记录        （记录不属于读者，是"关联"；读者没了记录要留档）
读者 —— * 图书            （借来的书不属于读者 → 关联，并标多重性）

画出来：

  ┌───────────┐1        *┌───────────┐
  │  Reader   │──────────>│   Book    │
  ├───────────┤           ├───────────┤
  │ - name    │           │ - title   │
  │ - id      │           │ - onShelf │
  │ - count   │           ├───────────┤
  ├───────────┤           │ + borrow()│
  │ + borrow()│           │+ giveBack()│
  └───────────┘           └───────────┘
        │ 1                      △ *   （组合，菱形指向整体）
        │                        │
        │ *              ┌───────────────┐
  ┌───────────┐          │   Library     │
  │ LoanRecord│<────────◆├───────────────┤
  ├───────────┤  *     1 │ - books:Book[]│
  │ - outDate │          │ - records[]   │
  │ - dueDate │          ├───────────────┤
  └───────────┘          │ + addBook()   │
                         │ + record()    │
                         └───────────────┘

五、需求 → 用例 → 类图：一条落地链

真实项目里，建模通常不是从零开始的，而是沿着这条链往下走：

① 需求描述（自然语言）    "读者能借书、还书，管理员能查在架图书"
        ↓  用【用例图】梳理"谁能用系统做什么"
② 用例（谁 + 做什么）     读者：借书 / 还书；管理员：查询
        ↓  对每个用例，走【四步建模法】
③ 类图（有哪些类、怎么连）  Reader / Book / Library / LoanRecord
        ↓  对复杂场景，用【时序图】理清调用顺序
④ 时序图（对象怎么来回配合）读者 → 图书.borrow() → 图书馆.record()

一句话：用例图管"做什么"，类图管"有什么"，时序图管"怎么跑"。

六、画完之后：自问三句

图不是画完就算好，收笔前必须过一遍这三问：

再加一问（很值钱）："如果我明天要加一个新需求（比如'预约'），这张图会怎么变？" ——改动小的图，是好图（这就是 9.2.2 说的"改动范围收敛"，在建模阶段就先验一遍）。

七、建模不是一次性的

最后一件必须记住的事：

代码变了，图要跟着改；否则图就从"资产"变成"负债"。

• 图过时的危害：新人照着旧图理解代码，会被误导——比没有图更糟。
• 现实的取舍：不要求图和代码逐行对应。只保持"关键结构"同步（有哪些主要类、谁继承谁、谁拥有谁）。
• 笨但有效的方法：把图放在代码旁边，改结构时顺手改一笔；或者在关键节点（版本发布、大改之前）统一对一次。

这跟测试的道理是一样的：不维护的东西，就不能指望它有用。

八、动手 Demo：从一句话需求走到类图

需求（一句话）：

"老师布置作业，学生提交作业，系统记录成绩。"

第①步：圈名词 → 老师、作业、学生、成绩（系统本身不算类）

第②③步：列属性与行为

第④步：定关系

看到什么算成功：你能画出四格方框 + 两条菱形线 + 一条普通实线，并说清"为什么 Score 对 Homework 是组合而不是关联"（分数不能脱离那次作业独立存在）。

30 秒实验：加一个需求——"学生可以补交作业，但会被标记"。你需要在图里改什么？

→ ① Homework 加一个方法 + markLate() : void；② Score 可能要加 - late : bool。注意：Teacher 和 Library 式的"大管家"类一个字都不用改——因为改动被关在了"作业自己的事"里。这就是 9.2.2 那句"谁变了就改谁"在建模阶段的提前演练。

九、常见误区

1. "建模就是画好看的图"——不。建模的核心产出是想清楚的过程：哪些类、各自职责、什么关系。图只是这个过程的记录。
2. "每个名词都要建类"——过头了。很多名词只是属性（借书证 → 读者的一个字段）。类越多，维护成本越高。
3. "建模一次做完就不用动了"——图是活的。代码演进，图要跟着走；否则它就从资产变成了"看起来很有用的误导"。
4. "必须先画完图才能写代码"——不必这么重。小项目在纸上画十分钟就够了；关键是先想结构，再动手写，而不是"先写 500 行再补图"。建模的度，看项目大小。
5. "先定关系更省事"——顺序错了。先想清"有哪些类、各自是什么"，关系才会自然浮现；上来就纠结"这根线是聚合还是组合"，通常是因为还没想清这两个类是什么。
6. "图越细越好"——细节留给代码。类图里写清主要属性和行为即可；把每个局部变量、每个循环都画进图里，只会让它失去"一眼看懂"的价值。

• ☐ 9.4 小结（下一节）

相关笔记

• 统一建模语言的结构 —— 上一节：类图的符号怎么读
• 面向对象编程 —— 本节第一步用的方法："把名词圈出来"
• 面向对象的特点 —— is-a 用继承、has-a 用包含
• 小结 —— 下一节：本章收束
• 🔷 C++基础 · 索引 —— 全课路线图