本章主軸#
本章以最低限度的篇幅，帶過閱讀本書圖示所需的 UML（Unified Modeling Language，統一塑模語言）知識。重點放在兩種圖：類別圖（Class diagram）與互動圖（Interaction diagram）。
什麼是 UML#
UML 是一種視覺化的塑模語言，意即一套有語意的繪圖記號，用來描繪程式中物件與物件之間的關係。它在不同階段提供不同類型的圖：
| 開發階段 | 常用 UML 圖 |
|---|---|
| 分析（Analysis） | Use Case 圖、Activity 圖 |
| 物件互動 | Interaction 圖（最常見的是 Sequence 圖） |
| 設計（Design） | Class 圖、State 圖 |
| 部署（Deployment） | Deployment 圖 |
本書聚焦在設計，因此主要使用 Class 圖與 Sequence 圖。
為什麼要使用 UML#
- 溝通：與自己、團隊、客戶釐清想法
- 準確：避免冗長口述，有了圖示，能更快收斂理解
- 強迫思考：要把關係畫出來，就必須把它想清楚
敏捷文化中常呼籲「不必要的文件愈少愈好」。但即便如此，UML 仍能在概念層次上大幅降低溝通成本——關鍵是用得「恰到好處」，而非過度。
類別圖（Class Diagram）#
類別的三種表現方式#
UML 的類別以矩形表示，可顯示三層資訊：
- 只顯示類別名稱：用於不需細節的高層結構
- 顯示名稱 + 方法：搭配存取修飾符記號（
+/#/-） - 顯示名稱 + 方法 + 資料成員：完整呈現屬性與型別
Figure 2-1: 類別圖的三種變體——名稱、名稱+方法、名稱+方法+資料成員
存取修飾符記號#
| 記號 | 意義 |
|---|---|
+ | Public — 任何物件皆可存取 |
# | Protected — 只有此類別與其衍生類別可存取 |
- | Private — 只有此類別自身可存取 |
類別之間的關係#
is-a 關係（繼承）#
- 衍生類別以箭頭指向基底類別
- 基底類別名稱斜體表示為抽象類別（abstract class）
Figure 2-2: 類別圖呈現 is-a 關係——Point/Line/Square 皆繼承自抽象 Shape
has-a 關係（包含）#
UML 中區分為兩種，與 GoF 書中相反：
| 關係 | 記號 | 說明 |
|---|---|---|
| 聚合（aggregation） | 空心菱形 ◇ | 被包含的物件可獨立存在（如機場與飛機） |
| 組合（composition） | 實心菱形 ◆ | 被包含的物件是包含者的一部分（如汽車與輪胎） |
Figure 2-3: has-a 關係——Airport 聚合 Aircraft，Aircraft 衍生為 Jet 與 Helicopter
Figure 2-4: 組合（實心菱形）與 uses 關係（虛線箭頭）
GoF 一書出版於 UML 標準化之前，其用詞與 UML 相反。本書採用 UML 的定義。
uses-a 關係（依賴）#
- 以虛線箭頭表示一個類別「使用」另一個類別
- 又稱為依賴關係（dependency relationship）
基數（cardinality）#
類別圖可標示「一個物件擁有多少個另一物件」：
0..1、0..*、1、4..5、*等寫法- 機場可以擁有 0 到 N 架飛機；一架飛機在 0 或 1 個機場
Figure 2-6: Airport 與 Aircraft 的基數標示——0..1 與 0..*
Figure 2-7: Car 與 Tire 的基數標示——4..5 與 1
沒有標示基數時不代表「只有一個」，而是「未指定」。
註記（note）#
- 形狀像折角的便條紙
- 連到某個類別時，以線段標示僅針對該類別
Figure 2-5: 含註記（note）的類別圖——折角紙片狀符號
互動圖：Sequence Diagram#
類別圖只表達靜態結構；要呈現物件如何隨時間互動，需用互動圖，最常見的就是 Sequence 圖。
閱讀方式#
- 由上而下 閱讀
- 每個矩形代表一個物件，可以用
objectName:ClassName的形式表達 - 垂直線代表物件的「生命線（lifeline）」
- 橫線代表物件之間的訊息傳遞
訊息傳遞 vs 呼叫方法#
物件之間溝通稱為「送訊息（sending a message）」，而非「呼叫方法」。
「送訊息」隱含一個關鍵差異：你只是請對方做某件事，由對方自己決定該如何做。這是物件導向責任轉移的根本原則，與程序式程式設計大相逕庭。
使用 UML 的心態#
不要拘泥於「正確的畫法」，而要思考「如何最有效地傳達設計概念」。
若擔心對方看不懂某個記號，附上一段註記說明即可。重點永遠是清晰（clarity）。
但這不代表可以隨意使用非標準記號，否則反而失去了 UML 共通語言的價值。