系統建模需要精確性。當架構師與開發人員規劃複雜的軟體結構時，組件之間的關係決定了系統的行為、擴展性以及應對變更的能力。在組合結構圖中，兩種特定的關係類型經常引起混淆：聚合與組合。儘管它們都代表部分-整體關係，但其差異決定了所有權、生命週期管理以及依賴強度。
理解這些細微差別並非僅僅是學術上的需求。它會影響記憶體管理的方式、資料持久化的機制，以及不同子系統之間的耦合程度。本指南深入探討這些結構性概念，超越基本定義，進一步探討它們在系統設計中的實際影響。
🏗️ 基礎：組合結構圖
組合結構圖展示了分類器的內部結構。它顯示了分類器如何被劃分為嵌套的組件，以及這些組件如何透過埠與連接器相互互動。在這個內部結構中，部分與整體的連結方式具有重大意義。
想像一個複雜的組裝結構。你有一個中央單元，並將較小的單元連接到它。有時，當中央單元被摧毀時，較小的單元仍然存在；而有時，當中央單元被摧毀時，較小的單元也隨之消失。這種區別正是聚合與組合之間的核心差異。
- 組合結構圖專注於內部架構。
- 部分-整體關係定義這些內部組件之間的連結方式。
- 所有權決定誰對部分的生命週期負責。
🤝 聚合：弱部分-整體關係
聚合代表一種關係，其中一個物件（整體）包含或引用另一個物件（部分），但該部分可以獨立存在。這種關係通常被描述為「共享」或「弱」關係。在此情境下，部分的生命週期並未嚴格依附於整體的生命週期。
🔍 聚合的主要特徵
- 獨立性： 部分可以在沒有整體的情況下存在。
- 共享所有權： 部分可能同時屬於多個整體。
- 弱耦合： 整體的變更不一定影響部分的存在。
- 方向性： 通常以一條線搭配在整體端的開放菱形來表示。
考慮一個大學與其系所的場景。系所存在於大學結構之中。然而，如果大學關閉某棟建築，系所物件本身可能仍會保留在資料庫或記憶體中以供存檔，或可能被重新分配至另一個行政單位。更準確地說，考慮一個隊伍與其隊員。如果隊伍解散，隊員仍然作為個人存在。他們可以加入另一支隊伍。隊員並非在嚴格的生命週期意義上被隊伍獨佔所有。
🧩 實作上的影響
在建模聚合時，你承認存在依賴關係，但並非創建依賴關係。管理「整體」的程式碼或邏輯無需建立「部分」。部分可以被注入、作為參數傳遞，或從共享資源池中取得。這降低了初始化邏輯的複雜度。
實作上的重點：
- 無建構函式依賴： 您無需在整體的建構函式中建立部分。
- 參考傳遞 整體持有對部分的參考（指標或ID）。
- 垃圾回收： 毀滅整體不會自動觸發部分的毀滅。
💥 組合：強烈的部分-整體關係
組合代表一種更強的聚合形式。它暗示獨佔所有權。部分是整體的不可或缺的組成部分，其生命週期與整體的生命週期嚴格綁定。如果整體被摧毀，部分也會隨之被摧毀。
🔍 組合的關鍵特徵
- 依賴性： 部分無法在沒有整體的情況下存在。
- 獨佔所有權： 一個部分在同一時間只能屬於一個整體。
- 強耦合： 整體的建立與毀滅決定了部分的建立與毀滅。
- 方向性： 以一條線表示，整體一端帶有實心菱形。
想像一棟房子及其房間。房間的存在依賴於房子的存在。如果房子被拆除，房間在該情境下便不再作為功能性實體存在。你無法將一個房間從一棟房子移至另一棟房子，而不根本改變其身份。同樣地，考慮一輛汽車及其引擎。雖然引擎可以拆下維修，但在汽車存在的背景下，特定的引擎實例是不可或缺的。如果汽車被報廢，那個特定的引擎配置也就實際上消失了。
🧩 實作上的含義
在建模組合時，整體負責部分的存在。這通常表示在整體內部進行實例化。
- 建構函數依賴： 整體通常在初始化期間創建部分。
- 資源管理： 整體必須確保當整體被摧毀時，分配給部分的資源被釋放。
- 生命週期同步： 部分無法在多個整體之間共享。
⚖️ 聚合與組合：詳細比較
為了釐清兩者的差異，我們可以將這些概念並列比較。下表分解了與系統架構和圖示相關的操作差異。
| 特徵 | 聚合 | 組合 |
|---|---|---|
| 所有權 | 共享或弱 | 獨佔 |
| 生命週期 | 獨立 | 依賴 |
| 建立 | 外部於整體 | 內部於整體 |
| 毀滅 | 整體死亡 → 部分存活 | 整體死亡 → 部分死亡 |
| 關聯 | 可有多向關聯 | 嚴格單向擁有 |
| 符號 | 空心菱形 (◇) | 實心菱形 (◆) |
| 類比 | 隊伍與球員 | 房屋與房間 |
🛠️ 組合結構圖中的視覺符號
在組合結構圖中，這些關係透過分類器內部元件之間的特定連接器來呈現。此符號有助於開發人員與架構師快速理解結構限制，而無需閱讀程式碼。
- 連接器： 一條連結容器部分與包含部分的直線。
- 菱形（聚合）： 容器側的空心菱形表示聚合。這表示關係為「擁有」關係，但無嚴格的所有權。
- 菱形（組成）： 容器側的實心菱形表示組成。這表示具有嚴格所有權的「部分」關係。
雖然視覺符號是標準的，但其解釋取決於設計階段所賦予的語義意義。實心菱形代表一種合約：「我對此部分的生命負責。」
🔄 生命週期管理與所有權規則
這些關係中最關鍵的方面之一是它們如何影響物件的生命週期。這在記憶體管理、資料庫交易和資源釋放方面尤為重要。
🗑️ 破壞場景
當容器物件從記憶體或系統中移除時：
- 組成場景： 系統會遞迴地破壞所有組成的部分。如果你有一份包含頁面的文件，刪除文件也會刪除所有頁面。系統不會嘗試將頁面保存到其他地方。
- 聚合場景： 系統會移除對該部分的參考。該部分仍保留在系統狀態中。系統必須確保該部分不會以破壞資料完整性的方式被遺棄，但該部分本身不會被破壞。
🔁 重新分配的可能性
組成禁止重新分配。部分無法在不被重新創建或重建的情況下從一個整體移動到另一個整體。聚合允許重新分配。資源（例如列印機）可以被多台電腦聚合。如果電腦A關閉，列印機仍可為電腦B使用。
🌍 結構建模的現實世界場景
為了讓這些概念具體化，讓我們檢視企業系統中常見的抽象場景。
場景A：訂單處理系統
在訂單管理系統中，一個訂單包含訂單項目.
- 關係：組成。
- 理由： 訂單項目通常在沒有訂單的情況下沒有意義。在此特定模型中，你通常不會獨立於訂單環境單獨銷售單一項目。如果訂單被取消（破壞），與其相關的訂單項目會從活躍環境中刪除。
場景B：員工目錄
一個部門包含員工.
- 關係：聚合。
- 理由： 員工獨立於部門存在。他們可能休假、調任或被解僱。如果部門重組，員工物件仍然存在。這種關係是一種集合，而非所有權。
情境C：金融投資組合
一個 投資組合持有 股票.
- 關係： 聚合。
- 理由： 股票在市場中存在，無論哪個投資組合持有它。單一的股票實例可能被多個投資組合物件所引用。銷毀一個投資組合不會銷毀股票資料。
🚧 常見陷阱與誤解
設計師經常混淆這兩個概念，導致原本應為鬆散耦合的關係變成了緊密耦合，反之亦然。以下是一些應避免的常見錯誤。
- 假設組合意味著資料持久化： 組合在模型中定義了生命週期關係。除非底層實作強制執行，否則它不會保證資料庫的級聯刪除。然而，模型應反映設計意圖。
- 將組合用於共享資源： 如果兩個組件需要共享單一資源實例（例如資料庫連接池），則組合是錯誤的選擇。應使用聚合。組合會阻止共享。
- 忽略「部分」定義： 在組合結構圖中，「部分」是一個具體的實例。如果你在建模類本身，你實際上是在建模類關聯。請確保你區分了類定義與實例關係。
- 過度使用組合： 組合會產生強依賴性，這可能使重構變得困難。如果你將模組組合進主應用程式，而你需要替換該模組，則必須重新建構主應用程式的結構。聚合則能提供更高的彈性。
📈 對系統設計與維護的影響
在聚合與組合之間的選擇會影響軟體的長期可維護性。這也影響團隊與程式碼庫的互動方式。
🔒 耦合與內聚
組合增加了容器內部的內聚性。容器會負責部分的內部邏輯。這通常有利於封裝。然而，它也增加了耦合性。容器若沒有部分就無法正確運作。
聚合降低了內聚性。容器依賴於部分，但部分本身具有獨立的存在。這可能導致較鬆散的耦合，使組件更容易獨立測試。
🧪 測試策略
單元測試會受到這些選擇的影響。
- 組合： 在測試整體時，你通常會隱式地測試部分。模擬部分可能需要重新建立整體的狀態。你可能需要測試生命週期邏輯（建立/銷毀）。
- 聚合： 您可以輕鬆地注入模擬或存根。該部分是外部的。這促進了對該部分邏輯的獨立測試，使其與容器邏輯分離。
📝 決策指南
在設計過程中遇到部分-整體關係時，請提出這些具體問題，以確定正確的關係類型。
- 該部分在沒有整體的情況下是否仍能成立？
如果答案是肯定的，傾向於使用聚合。如果否，傾向於使用組合。 - 該部分能否屬於多個整體？
如果答案是肯定的，則必須使用聚合。組合禁止存在多個所有者。 - 誰負責該部分的創建？
如果整體負責創建它，則很可能是組合。如果由外部管理器創建，則很可能是聚合。 - 如果整體被刪除，會發生什麼情況？
如果該部分必須被刪除，請使用組合。如果該部分必須存活，請使用聚合。
🔗 與其他圖形類型的互動
組合結構圖並非孤立存在。這些關係通常也出現在類圖中。
- 類圖： 使用聚合和組合來定義類的屬性和關聯。符號完全相同。
- 順序圖： 生命周期關係會以創建訊息的形式表現。組合可能在順序中顯示容器向部分發送的「創建」訊息。
- 部署圖： 物理節點可能聚合軟件實體。如果伺服器主機應用程式，這是聚合還是組合？通常為聚合，因為伺服器可能主機多個應用程式，且應用程式可移動。
🧠 面向對象設計中的細節
在現代程式語言中，這些概念對應於特定的設計模式。
依賴注入
依賴注入是一種自然支持聚合的技術。您將依賴項注入建構函式或設值方法中。容器並非依賴項的所有者。這促進了可測試性和靈活性。
值對象與實體
在領域驅動設計中，值對象通常被組合進實體中。它們自身沒有身份，僅在實體的上下文中存在。這是一種典型的組合關係。引用其他實體的實體通常通過聚合來實現（例如，客戶聚合了多個訂單）。
🛡️ 安全性與資料完整性
選擇組合可以為資料完整性提供安全網。透過綁定生命週期，可確保孤立資料不會累積。例如，如果「會話」組合了「使用者上下文」，關閉會話可確保上下文被清除。在此處使用聚合可能會導致過時資料殘留在記憶體或資料庫中。
然而，聚合可提供對意外破壞的安全保障。如果「報表產生器」聚合了「資料來源」，關閉產生器不應清除資料來源。資料來源必須能承受產生器的暫時故障。
🔍 分析現有模型
在審查遺留圖表時，您可能會發現模糊之處。如何解釋一個不清晰的關係？
- 尋找生命週期邏輯： 檢查程式碼或資料庫觸發器。刪除 A 時是否也會刪除 B？這表示組成關係。
- 尋找共享關係： B 是否出現在多個 A 中？這表示聚合關係。
- 檢查命名慣例： 有時「Manager」暗示聚合關係（管理現有的資源），而「Builder」則暗示組成關係（建立資源）。
🎯 結構完整性總結
在聚合與組成之間的選擇是一個基本的架構決策。它定義了責任範圍與系統內存在性的流動。聚合允許彈性與共享，將部分視為可獨立存在的實體，可被組合使用。組成則強制設立嚴格的界限，確保部分是整體不可或缺的一部分，無法在整體被摧毀後獨立存在。
透過在組合結構圖中嚴謹地應用這些概念，您將建立出能準確反映軟體執行時期行為的模型。這種清晰性可減少技術負債，簡化新開發人員的上手過程，並為系統的演進奠定穩固的基礎。
務必根據組件的生命週期需求來驗證您的設計選擇。一張繪製正確、使用正確菱形符號的圖表，能在開發週期後段節省數小時的除錯與架構混淆時間。