在物件導向分析與設計（OOAD）的領域中，系統的結構完整性在很大程度上取決於類別之間的關係。這些關係定義了系統架構，決定資料流動方式，並規範執行環境中物件的生命週期。其中兩個最常被討論的概念是關聯與聚合雖然它們在圖示上可能看起來相似，但就擁有權、依賴性與記憶體管理而言，其語義含義有顯著差異。
理解這些關係之間的細微差別，對於建立可維護且可擴展的系統至關重要。本指南探討物件導向程式設計中結構化建模所涉及的技術差異、生命週期影響與設計模式。
理解結構關係 🏗️
在深入探討特定關係類型之前，必須認識到物件很少孤立存在。它們透過互動來執行複雜任務。這些互動被建模為類別實例之間的連結。在統一模型語言（UML）中，這些連結以連接類別方框的線條來呈現。線條的性質——實線、虛線、空心或填滿——表示關係的類型。
三種主要的結構關係為：
- 關聯： 類別之間的一般連結。
- 聚合： 一種特定的關聯，表示具有弱擁有權的「整體-部分」關係。
- 組合： 一種較強的聚合形式，其中部分無法獨立於整體而存在。
在本討論中，重點仍放在關聯與聚合之間的差異，因為這兩者對開發人員與架構師而言通常最為模糊。
關聯詳解 🔗
關聯代表一種結構關係，其中一個類別的物件與另一個類別的物件相連。它描述了一個類別如何知道另一個類別並能與其通訊。這是物件互動中最基本的構建單元。
關聯的關鍵特徵
- 一般連接性： 這表示 Class A 的實例可以存取 Class B 的實例。
- 方向性： 關聯可以是單向（單向導航）或雙向（雙向導航）。
- 多重性： 這定義了一個類別的實例與另一個類別的實例之間的數量關係。常見的符號包括一對一（1:1）、一對多（1:N）與多對多（N:N）。
- 不暗示擁有權： 預設情況下，關聯並不代表一個類別擁有另一個類別。兩個物件都可以獨立存在。
設計中的範例
考慮一個涉及學生 和 教授。一位教授教導多名學生，而一名學生也可以由多位教授教導。這是一種典型的多對多關聯。
- 一個 學生物件會持有對一個 教授物件的參考，以存取課程細節。
- 一個 教授物件會持有 學生物件的清單，以管理成績。
- 無論學生或教授，當其中一方從關係中移除時，另一方都不會消失。
另一個例子涉及一位 駕駛員 和一輛 汽車。駕駛員駕駛汽車，但即使駕駛員離開，汽車依然存在。這種關係具有功能性，但在嚴格的生命週期意義上並非擁有關係。
導航與責任
在建模關聯時，開發人員必須決定由誰啟動互動。如果關係是單向的，僅有一個類別持有對另一個類別的參考。這能降低耦合度，並簡化垃圾回收邏輯。如果是雙向關係，則兩個類別都必須管理參考，以維持一致性。
聚合的定義 📦
聚合是一種特殊形式的關聯。它代表「擁有」關係，暗示一個整體物件包含一個部分物件。然而，關鍵區別在於生命週期與所有權。
弱所有權的概念
在聚合關係中，部分物件可以獨立於整體物件存在。即使整體物件被銷毀，部分物件依然有效。這通常被描述為共享所有權的情境。
- 整體物件： 容器或管理者。
- 部分物件： 被管理的組件或實體。
- 獨立性： 該部分具有獨立於整體的生命周期。
設計中的範例
考慮一個部門 和 員工。部門由員工組成。然而，若部門解散，員工並不會消失；他們可能僅被重新分配至另一部門，或離開組織。
- 該部門類別包含一組員工物件。
- 該員工物件並不需要依賴部門來維持其核心存在。
- 這種關係通常在UML中以「整體」側的空心菱形來表示。
另一個範例是圖書館 和 書籍。圖書館包含書籍。若圖書館建築被拆除，書籍仍然存在；它們可以被移至新地點。書籍並非由圖書館創造，也不會隨著圖書館的消失而消亡。
實作細節
在程式碼中，聚合通常透過參考或指標來實作。容器類別不會在內部建立部分類別；部分通常透過建構函式或設定方法傳入。
- 建構函式注入： 當整體建立時，提供該部分。
- 設定方法注入： 該部分在建立後被指派給整體。
- 無破壞： 當整體被銷毀時，整個類別不會明確地銷毀其部分。
組成 vs 聚合 ⚖️
要完全理解聚合，有必要簡要地將其與組成進行對比。組成常常是令人困惑的點。雖然聚合暗示弱擁有關係，但組成則暗示強擁有關係。
- 聚合： 部分可以在沒有整體的情況下存在。（範例：房屋與窗戶）。
- 組成： 部分無法在沒有整體的情況下存在。（範例：訂單與明細項目）。
在組成中，部分的生命周期與整體的生命周期緊密關聯。如果整體被垃圾回收，部分也會被銷毀。在聚合中，部分在整體被銷毀後仍能存活。
關鍵差異一目了然 📊
下表總結了關聯與聚合之間的結構和語義差異，以方便快速參考。
| 特徵 | 關聯 | 聚合 |
|---|---|---|
| 關係類型 | 類別之間的一般連結 | 「擁有」關係（整體-部分） |
| 擁有權 | 未暗示擁有權 | 弱擁有權 |
| 生命週期 | 獨立的生命週期 | 部分可以在沒有整體的情況下存在 |
| UML 表示法 | 實線 | 帶空心菱形的實線 |
| 程式碼實作 | 參考或指標 | 參考或指標（無內部建立） |
| 依賴 | 低至中等 | 中等 |
生命週期與記憶體管理 💾
這些關係之間的差異對記憶體管理有實際影響。在使用手動記憶體管理或明確垃圾回收的語言中，了解誰擁有誰至關重要，以避免記憶體洩漏或懸空指標。
記憶體配置
- 關聯：兩個物件各自配置自己的記憶體。連結僅是從一個位址指向另一個位址的指標。破壞其中一個物件不會影響另一個物件的記憶體。
- 聚合：容器持有參考。它並未「擁有」部分的記憶體。當容器被破壞時，執行時不會自動回收部分的記憶體。
垃圾回收的影響
在受管理的執行時環境中，當物件不再可達時就會被回收。如果關聯或聚合產生了循環引用，則需要特定的垃圾回收策略來檢測並清除這些循環。
- 循環引用：類別 A 參考類別 B，而類別 B 又參考類別 A。若未妥善處理，兩者可能均無法被回收。
- 弱參考： 在某些設計中，關聯會使用弱參考來打破循環，並允許垃圾回收繼續進行。
設計穩健的系統 🛡️
選擇正確的關係類型會影響軟體的耦合度與內聚度。高耦合會使系統脆弱且難以測試。高內聚則確保模組具有單一且明確的用途。
降低耦合
與組合相比，聚合通常能降低耦合度。由於部分並非由整體創建，因此整體對部分具體實作的依賴較少。這使得元件更易於替換。
- 依賴注入： 將物件傳遞給建構函式（聚合風格）可讓容器在不需知道部分具體實作的情況下運作。
- 介面分割： 整體可以透過介面與部分互動，進一步降低關係的耦合度。
內聚與責任
每個類別都應有明確的責任。聚合有助於釐清「整體」負責管理集合，而「部分」則負責其自身的內部狀態。
- 整體責任： 管理清單、確保唯一性，或在集合上強制執行業務規則。
- 部分責任： 處理其自身的資料驗證與內部邏輯。
常見的模型設計陷阱 ⚠️
即使經驗豐富的建築師在定義關係時也可能犯錯。了解常見的陷阱有助於保持模型的準確性。
- 過度使用聚合：有時，關係被建模為聚合，但實際上僅是簡單的關聯。如果不存在「整體」的概念，則聚合是錯誤的。
- 生命週期不明確： 如果無法確定零件是否應在整體被銷毀後繼續存在，則關係類型未明確。記錄意圖至關重要。
- 導航混淆： 在僅需單向導航時假設雙向導航，會增加不必要的複雜性，並可能導致資料不一致。
- 混淆關聯與聚合： 所有聚合都是關聯，但並非所有關聯都是聚合。『擁有』測試是關鍵區別。
實作的最佳實務 ✅
為確保清晰度與可維護性，實作程式碼中的結構關係時應遵循以下指引。
1. 命名要明確
方法和變數名稱應反映關係。使用如擁有者, 父物件，或集合 代表聚合，而連結, 夥伴，或參考 代表一般關聯。
2. 記錄生命週期意圖
註解或文件應明確說明零件物件是否預期會在整體物件之後繼續存在。這可防止未來開發者意外刪除共用資源。
3. 強制執行多重性
確保程式碼強制執行模型中定義的多重性。如果關係是一對多，程式碼中的集合應反映此特性。在關係為必要時，不得允許空值。
4. 避免過深嵌套
雖然關係可以嵌套，但過深的關聯鏈（A 連接到 B，B 連接到 C，C 連接到 D）可能會使導航變得困難。盡可能地扁平化結構，以提升可讀性和性能。
5. 測試邊界條件
當整個物件被銷毀時，若關係為聚合（Aggregation），請確認各部分仍保持完整；反之，若關係為組合（Composition），則需確認各部分已被正確清除。
結構設計總結 🎯
在關聯（Association）與聚合（Aggregation）之間的選擇不僅僅是語法上的決定，更是一種語義上的選擇，會影響系統的架構。透過正確地建模這些關係，開發者能確保系統的生命週期管理具有可預測性，並有效管理依賴關係。
關聯提供了一般性連接的彈性，而聚合則提供了一種結構化的方式來管理獨立實體的集合。這兩者都是物件導向分析與設計工具箱中不可或缺的工具。掌握它們的應用，將使系統更易於理解、測試與隨時間演進。
在設計下一代軟體時，請花時間分析類別之間關係的本質。問問自己，部分是否能在沒有整體的情況下存在。如果答案是肯定的，那麼聚合（Aggregation）很可能是正確的選擇。如果連結僅為功能性而無包含關係，則關聯（Association）才是適當的途徑。