在物件導向分析與設計（OOAD）的領域中，定義物件之間如何互動，與定義物件本身同等重要。在各種結構關係中，組成關係因其強制執行嚴格的所有權與生命週期依賴性而顯得突出。在建模複雜系統時，選擇使用組成關係而非簡單關聯或聚合，會根本性地改變資料流動方式與記憶體管理方式。
本指南探討類別結構中組成關係的運作機制。我們將檢視其理論基礎、實際實作模式，以及對系統架構的影響。重點始終放在結構完整性與邏輯一致性上，避免不必要的複雜性，同時確保設計的穩健性。
🧩 在OOAD中定義組成關係
組成關係是一種特殊形式的關聯，代表「部分對整體」的關係。與兩個獨立實體之間的一般連結不同，組成關係暗示部分無法獨立於整體而存在。這種依賴性是結構上的，而非僅僅是邏輯上的。
- 所有權： 整體物件擁有其元件的生命週期。
- 存在性： 若整體被銷毀，其部分也會隨之被銷毀。
- 可見性： 部分通常在整體的範圍之外不可見。
考慮一個簡單的層次結構。一個房屋類別可能包含多個房間物件。若房屋被拆除，則房間物件在該情境下便不再存在。它們不會自動遷移到另一棟房屋。這正是組成關係的本質。
📊 組成關係與聚合關係的比較
組成關係與聚合關係之間常產生混淆。兩者都是關聯的形式，但在生命週期管理與耦合強度方面有顯著差異。理解此區別對於準確建模至關重要。
| 特徵 | 組成關係 | 聚合關係 |
|---|---|---|
| 所有權 | 強所有權 | 弱所有權 |
| 生命週期 | 依賴 | 獨立的 |
| 創建 | 由整體創建 | 外部創建 |
| 破壞 | 隨整體一起刪除 | 可獨立於整體存在 |
| 範例 | 心臟與身體 | 學生與大學 |
在聚合中，一個大學管理一組學生物件。如果大學關閉，學生仍然存在；他們只是轉往另一個機構。在組合中，一個身體管理一個心臟。如果身體死亡，心臟便不再作為活體器官運作。
⏳ 生命周期管理與記憶體
組合的一個主要技術影響是記憶體如何被處理。在許多程式設計範式中，組合物件負責為其元件配置和釋放記憶體。
- 配置：當組合物件被實例化時，它會實例化其各部分。
- 釋放：當組合物件被破壞時，它會遞迴地破壞其各部分。
- 例外情況：如果需要外部存取，可能需要明確的元件參考。
這種自動管理降低了記憶體洩漏和懸空指標的風險。然而，它也帶來了必須與聚合的彈性權衡的僵硬性。如果一個元件需要在多個組合之間共享，組合通常不是正確的選擇。
🛠️ 實作模式
實作組合需要仔細注意參考傳遞的方式。以下模式有助於維持關係的完整性。
1. 建造者注入
最常見的方法是將組件實例傳遞給組合對象的建構函式。這確保了組合對象無法在缺少必要部分的情況下存在。
- 確保初始化狀態。
- 如果屬性為只讀，則強制引用的不可變性。
- 防止建立無效狀態。
2. 封裝式存取
組件通常應被隱藏。提供一個傳回組件參考的取得方法，可能會破壞生命週期的封裝性。如果客戶端收到直接的參考，可能會以損害整體的方式修改該組件。
- 使用傳回複本或介面的存取方法。
- 限制對組件物件的直接修改。
- 確保組合對象控制修改邏輯。
3. 遞迴銷毀
當組合對象被移除時，系統必須確保所有嵌套的組件都被清理。在具有垃圾回收機制的語言中，這通常是隱式進行的。在手動記憶體管理中，組合對象必須明確地對其組件調用銷毀方法。
🔗 與設計原則的關係
組合與幾個核心設計原則密切一致，這些原則指導著可維護的軟體架構。
單一職責原則
組合鼓勵將大型類拆分成更小、專注的組件。每個組件負責整體的特定方面。這種分離使程式碼更易於測試和修改。
開閉原則
透過組合行為而非繼承，類別可以在不修改現有程式碼的情況下進行擴展。您可以將一個組件替換為另一個實現相同介面的組件，從而動態改變行為。
依賴倒置
高階模組不應依賴低階模組。兩者都應依賴抽象。組合允許組合對象依賴組件的介面，從而使組件的實作可以變更而不影響組合對象。
🚧 常見挑戰
雖然組合提供了穩健性，但也引入了架構師必須應對的特定挑戰。
- 循環依賴：如果兩個組合對象互相引用，可能會形成一個循環，使生命週期管理變得複雜。打破這些循環通常需要引入中介者或使用弱引用。
- 測試複雜度：測試一個組合對象需要設置其內部結構。如果組件之間緊密耦合，模擬它們會變得困難。
- 序列化：儲存和載入物件圖形可能很棘手。反序列化的順序很重要。通常必須先重建整體，才能重建各部分。
- 效能開銷：建立和銷毀嵌套物件會增加計算成本。在高性能量系統中，必須衡量此開銷。
🔄 重構聚合至組成
隨著系統的演進，關係可能需要調整。常見的重構任務是在所有權變得更明確時，將聚合轉換為組成。
- 識別轉變： 判斷零件是否應隨整體一同被銷毀。
- 更新生命週期邏輯： 確保組成物件負責零件的銷毀。
- 檢視參考： 移除允許獨立存在的外部參考。
- 更新測試： 驗證新的生命週期約束是否成立。
反之，當零件必須被共享時，則需要將組成轉換為聚合。這涉及使零件的建立獨立於整體。
🌐 實際世界中的模型情境
讓我們看看這如何應用於常見的領域模型。
情境 1：文件管理系統
一個 文件包含 頁面物件。如果文件被刪除，頁面將不再相關。在此情境下，組成是合適的。文件控制頁面的順序與存在性。
情境 2：電子商務訂單
一個 訂單包含 訂單項目物件。當訂單完成並歸檔時，項目仍為歷史資料。然而，若訂單被作廢，項目則會被移除。這表示訂單的活躍狀態應使用組成。
情境 3：金融投資組合
一個 投資組合持有 資產 物件。資產通常存在於投資組合之外（例如，公開市場上的股票）。從投資組合中移除資產並不會摧毀該資產。在此情況下，聚合是正確的選擇。
⚖️ 決策框架
在決定是否實作組合時，請提出以下問題：
- 該部分是否在邏輯上僅屬於一個整體？
- 如果整體被移除，該部分是否也應隨之消失？
- 該部分的建立是否依賴於整體？
- 我們是否需要隱藏內部結構，以避免外部客戶直接存取？
如果這些問題的答案都一致為「是」，則組合很可能是正確的結構關係。如果答案為「否」，則應考慮使用聚合或關聯。
🛡️ 安全性與一致性
維持組合的一致性需要嚴格的驗證。組合物件永遠不應處於缺少必要部分的狀態。這通常透過以下方式強制執行：
- 建構函式驗證： 如果必要部分為 null，則拋出錯誤。
- 不變式（Invariants）： 在修改前後檢查條件是否成立。
- 私有欄位： 將對部分的參考保持為私有，以防止外部干擾。
這種層級的控制確保系統在執行期間始終處於有效狀態。它可防止使用者嘗試存取不存在文件的頁面等情境。
📈 可擴展性考量
隨著類別數量增加，組合樹的複雜度也可能上升。過深的巢狀結構可能導致：
- 初始化時間過長。
- 難以導航的路徑。
- 更難閱讀的物件圖。
設計者應盡可能追求淺層的層次結構。簡化結構通常能提升效能與可維護性。若一個組合物件包含另一個組合物件，請確保內部的組合物件不是外部組合物件的實作細節。
🧪 測試策略
測試以組合為主的系統需要特定的方法。
- 單元測試： 使用模擬物件（mocks）對其部分，獨立測試組合物件。
- 整合測試： 驗證生命週期事件是否在整個物件圖中正確觸發。
- 狀態測試： 確保組合對象無法被修改為無效狀態。
自動化測試應涵蓋銷毀路徑，以確保不會有資源洩漏。在記憶體資源有限的環境中，這尤其重要。
🔮 未來穩健的結構
以組合為設計核心，可為未來的變更做好準備。若需求轉變為允許部分共享，從組合轉向聚合僅是局部變更。從繼承轉向組合則是一種結構性轉變，通常能簡化層次結構。
透過優先考慮組合，開發者能建立模組化且穩健的系統。明確的所有權模型可減少對誰負責管理特定資料的模糊性。