物件導向設計在很大程度上依賴於類之間的互動方式。當架構師繪製系統時，通常會從類圖開始。這個視覺藍圖定義了軟體內部的結構、屬性以及關係。在這個藍圖中，最關鍵的元素就是關係本身。具體而言，關聯、聚合與組合之間的區別決定了物件如何管理其生命週期與依賴關係。若誤解這些概念，可能會導致程式碼脆弱，當系統中某一部分發生變動時，物件會意外地失效。
這三種關係類型經常被混淆。它們都代表兩個類之間的「連結」，但這種連結的性質卻有顯著差異。在本指南中，我們將逐一剖析每種關係類型。我們將檢視它們的視覺表示、語義含義，以及它們如何轉化為實際的程式碼結構。結束後，您將具備清晰的心智模型，能夠將現實世界的情境對應到您的類圖中。
1. 關聯：基本連結 🔗
關聯是類圖中最普遍的關係形式。它代表兩個類之間的結構性連結。如果類 A 與類 B 有關聯，表示類 A 的物件會參考類 B 的物件。這是另外兩種關係建立的基礎。
關聯的關鍵特徵
- 方向性：關聯可以是單向的（一個箭頭）或雙向的（無箭頭或兩個箭頭）。單向表示類 A 知道類 B，但類 B 可能不知道類 A。
- 多重性：這定義了一個類的實例與另一個類的實例之間的數量關係。常見的符號包括「1」、「1..*」（一對多），以及「0..1」（零個或一個）。
- 可導航性：在程式碼中，這通常轉化為參考或指標。它決定了哪個物件持有另一個物件的記憶體位址。
- 角色名稱：關聯通常在線條的兩端標示名稱，用以表示物件所扮演的角色。例如，一個「客戶」擁有一個「帳單地址」。
範例情境：學生與課程 🎓
考慮一個管理學術紀錄的系統。一個學生類別與一個課程類別有關聯。這種關聯允許學生註冊課程。然而，課程可以獨立於特定學生存在。如果學生退學，課程記錄仍會保留在資料庫中。
- 視覺呈現： 一條連接兩個類別的直線。
- 含義： 課程的生命週期與學生無關。
- 程式碼對應： 一個參考變數，或資料庫表格中的外鍵。
何時使用關聯
當您需要在兩個可獨立存在的實體之間建立連結時，使用關聯。這是預設的關係類型。如果您不確定，可先從關聯開始，待生命週期依賴關係顯現後再進行調整。
2. 聚合：「擁有」關係 🧺
聚合是關聯的一種特殊形式。它代表「整體-部分」關係。在此情境下，整體類別包含或擁有部分類別。然而，聚合的定義特徵在於，部分可以獨立於整體而存在。
聚合的關鍵特徵
- 弱擁有權： 「整體」對「部分」的生命周期沒有獨佔控制權。
- 獨立性： 如果整體物件被銷毀，部分物件仍會繼續存在。
- 視覺表示： 一條直線，其「整體」端有一個空心（白色）菱形。
- 共享資源： 這通常用於模擬共享資源，其中多個整體可能引用相同的部分。
範例情境：系所與教授 👨🏫
想像一個大學結構。一個系所聚合教授 物件。系所是整體，而教授們是部分。
- 情境： 如果系所被解散或合併，教授們並不會消失。他們可能只是被重新分配到另一個系所。
- 程式碼對應： 一個參考的清單或集合。系所持有教授物件的清單，但並非獨佔地創建或銷毀它們。
常見的誤解
人們經常將聚合與簡單的關聯混淆。差別在於「整體-部分」關係的語義強度。在關聯中，連結僅是一種連接。在聚合中，連結暗示了一種層級結構，但並非嚴格的生命週期依賴。空心菱形是關鍵的視覺提示。
3. 組合：強擁有權 🔨
組合是關聯中最強的形式。與聚合一樣，它代表一種「整體-部分」關係。然而，部分無法獨立於整體存在。如果整體物件被銷毀，部分物件也會隨之被銷毀。這意味著獨佔擁有權。
組合的關鍵特徵
- 強擁有權： 整體負責部分的創建與銷毀。
- 依賴的生命週期： 部分若無整體，則毫無意義或存在。
- 視覺表示： 一條直線，其「整體」端有一個實心（黑色）菱形。
- 獨家存取： 零件通常一次只屬於一個整體。
範例情境：房屋與房間 🏠
考慮一個房地產模型。一個房屋由房間物件組成。
- 情境： 沒有「房屋」定義其上下文，你就無法擁有「房間」漂浮在空間中。如果房屋被拆除，房間實際上也隨之毀滅。它們不會移動到另一棟房屋。
- 程式碼對應： 房屋類別在內部實例化房間物件。房間物件並非從外部傳入；它們是房屋建構函式的一部分所創建的。
與聚合的比較
為什麼汽車與引擎是聚合，而房屋與房間是組合？
- 汽車與引擎： 如果汽車被報廢，引擎可能被回收並安裝到另一輛汽車上。引擎的價值超越了特定的汽車實例。這就是聚合。
- 房屋與房間： 房間由其牆壁和在特定房屋中的位置所定義。若不重新建造，將房間拆下並放置到其他地方是沒有意義的。這就是組合。
4. 側邊比較 📊
為確保清晰，我們可以直接比較三種關係類型。此表格突顯了生命週期、視覺符號和使用情境之間的關鍵差異。
| 特徵 | 關聯 | 聚合 | 組合 |
|---|---|---|---|
| 關係類型 | 通用連結 | 整體-部分（弱） | 整體-部分（強） |
| 生命週期 | 獨立 | 獨立 | 依賴 |
| 擁有權 | 無 / 共享 | 共享 | 獨佔 |
| 視覺符號 | 直線 | 空心菱形 (◊) | 實心菱形 (◆) |
| 範例 | 學生 – 課程 | 系所 – 教授 | 房屋 – 房間 |
5. 實作與程式碼對應 💻
雖然圖表提供了藍圖，但實際的實作發生在程式碼中。理解這些關係如何轉換至程式碼，對於維持記憶體完整性並避免記憶體洩漏至關重要。
程式碼中的關聯
在大多數程式語言中，關聯是透過參考變數來實作的。父物件持有指向子物件的指標。
- 儲存空間：子物件的記憶體會獨立配置。
- 初始化：子物件通常透過建構函式或設定方法傳入。
- 銷毀：刪除父物件不會自動刪除子物件。
程式碼中的聚合
聚合通常看起來像是一組參考的集合。父物件管理容器，但不管理內容。
- 儲存空間：父物件持有子物件參考的清單或陣列。
- 初始化：子物件在其他地方建立，並加入父物件的集合中。
- 破壞： 父物件停止引用子物件，但子物件會保留在記憶體中，直到垃圾回收或由另一個擁有者明確刪除。
程式碼中的組合
組合表示父物件負責建立和銷毀子物件。這在巢狀物件建立中經常出現。
- 儲存： 子物件是父類別的成員變數。
- 初始化： 子物件在父物件的建構函式內被實例化。
- 破壞： 當父物件超出作用域時，子物件也會被銷毀。
6. 常見陷阱與誤解 ❌
即使經驗豐富的設計師在建模這些關係時也會犯錯。以下是應避免的最常見錯誤。
陷阱 1：過度使用組合
為了強制嚴格的界限，很容易想對所有事物都使用組合。然而，這會使系統變得僵硬。如果一個「房間」是由「房屋」組成的，那麼在沒有複雜重構的情況下，很難將該房間移至另一棟房屋。只有當生命週期的依賴關係是絕對時，才應使用組合。
陷阱 2：忽略導航性
兩個類別相關，並不表示它們都必須知道對方。在關聯關係中，應考慮 Class B 是否需要指向 Class A 的參考。如果不需要，則畫單向箭頭。這能降低耦合度，並使測試更容易。
陷阱 3：混淆聚合與組合
這是最常見的混淆來源。請問自己：「如果父物件死亡，子物件是否也死亡？」如果答案是「否」，則為聚合；如果答案是「是」，則為組合。不要僅依賴視覺形狀，而應依賴業務邏輯。
陷阱 4：循環依賴
在定義關聯時，請確保不會產生會阻止編譯或導致堆疊溢出的循環依賴。例如，Class A 參考 Class B，而 Class B 又參考 Class A。雖然在某些情境下是合法的，但這可能使序列化和資料庫外鍵變得複雜。
7. 實際應用情境與重構 🏢
讓我們看看這些概念如何應用於複雜系統。我們將檢視一個銀行系統與一個電子商務平台。
銀行系統 🏦
考慮一個銀行帳戶系統。
- 客戶與帳戶（聚合）： 客戶擁有帳戶。如果客戶關閉其個人檔案，帳戶可能被歸檔或轉移，但帳戶記錄本身可能仍會保留以供審計用途。這通常是聚合。
- 交易與帳戶（組合）： 交易屬於帳戶。交易無法在沒有帳戶的情況下存在。如果帳戶被刪除，交易會被邏輯上移除或與其一同歸檔。這屬於組合。
電子商務平台 🛒
考慮一個訂單管理系統。
- 訂單與客戶（關聯）： 訂單由客戶下訂。若客戶帳戶被停用，訂單歷史仍會保留，以符合法律要求。這就是關聯。
- 訂單與項目（組成）： 訂單包含項目。若訂單被取消或刪除，項目將不再相關。它們是組成於訂單內部的。
8. 建模的最佳實務 🏗️
為維持清晰且穩健的設計，建立類別圖時請遵循以下指引。
- 從簡單開始： 從關聯開始。若發現需要管理生命週期，稍後再升級為聚合或組成。
- 保持一致： 若在「房間-房屋」中使用組成，則在同一張圖中不應對「窗戶-牆壁」使用關聯，除非有明確理由。一致性有助於圖表的可讀性。
- 記錄多重性： 始終明確標示基數（1、0..1、1..*）。沒有多重性的關係會造成歧義。
- 命名兩端： 為關係線的兩端加上標籤。「訂單」擁有「項目」比僅僅將「訂單」連接到「項目」更為清晰。
- 檢視生命週期： 定期檢視您的圖表。隨著需求變更，組成可能轉變為聚合。請更新模型以反映實際情況。
9. 資料庫影響 🗄️
類別圖通常會驅動資料庫結構設計。理解這些關係有助於決定外鍵與規範化方式。
- 關聯： 通常會在資料庫表格中產生外鍵，若關係為多對多，則會建立關聯表。
- 聚合： 與關聯類似。外鍵存在於「部分」表格中，指向「整體」表格。
- 組成： 通常會產生外鍵，但帶有特定限制。例如「刪除時級聯」規則。若父資料列被刪除，資料庫會自動刪除子資料列。
理解這些差異可避免資料完整性問題。若在程式碼中將關係建模為組成，但在資料庫中實作為簡單關聯，將可能導致孤立記錄。
10. 測試與驗證 ✅
針對這些關係進行單元測試，需特別關注物件狀態。
- 測試關聯： 確認參考存在且指向有效物件。檢查子物件是否能獨立存在。
- 測試聚合： 確認移除父物件不會導致子物件當機。檢查多個父物件是否可以引用同一個子物件。
- 測試組合：確認破壞父物件也會使子物件失效或被破壞。檢查子物件是否無法在沒有父物件的情況下被實例化。
11. 對設計清晰度的最後想法 🧠
設計類圖是一個迭代的過程。隨著系統的建立，你將不斷深化對聚合、組合與關聯的理解。目標不僅僅是畫出線條，更要傳達意圖。當開發人員閱讀你的圖表時，應能立即理解物件之間的關係以及它們的生命周期。
透過區分獨立連結與依賴生命週期，你將建立更易維護的系統。你可以避免刪除主要物件導致意外副作用的情況。你確保記憶體能被有效管理。這些關係不僅是學術概念；它們決定了資料流動與應用程式的穩定性。
花時間正確設定多重性。正確使用視覺符號。並始終確保圖表與程式碼的實際行為一致。當你的模型與實作相符時，結果將是一個穩健、可擴展且清晰的系統。