以下內容來自《Java設計模式》
1 合成複用原則
合成複用原則又稱爲組合/聚合複用原則(Composition/Aggregate Reuse Principle, CARP)，其定 義如下：
合成複用原則(Composite Reuse Principle, CRP)：儘量使用對象組合，而不是繼承來達到復 用的目的。
合成複用原則就是在一個新的對象裏通過關聯關係（包括組合關係和聚合關係）來使用一些 已有的對象，使之成爲新對象的一部分；新對象通過委派調用已有對象的方法達到複用功能 的目的。簡言之：複用時要儘量使用組合/聚合關係（關聯關係），少用繼承。
在面向對象設計中，可以通過兩種方法在不同的環境中複用已有的設計和實現，即通過組合/ 聚合關係或通過繼承，但首先應該考慮使用組合/聚合，組合/聚合可以使系統更加靈活，降低 類與類之間的耦合度，一個類的變化對其他類造成的影響相對較少；其次才考慮繼承，在使 用繼承時，需要嚴格遵循里氏代換原則，有效使用繼承會有助於對問題的理解，降低複雜 度，而濫用繼承反而會增加系統構建和維護的難度以及系統的複雜度，因此需要慎重使用繼 承複用。
通過繼承來進行復用的主要問題在於繼承複用會破壞系統的封裝性，因爲繼承會將基類的實 現細節暴露給子類，由於基類的內部細節通常對子類來說是可見的，所以這種複用又稱“白 箱”複用，如果基類發生改變，那麼子類的實現也不得不發生改變；從基類繼承而來的實現是 靜態的，不可能在運行時發生改變，沒有足夠的靈活性；而且繼承只能在有限的環境中使用 （如類沒有聲明爲不能被繼承）。
一般而言，如果兩個類之間是“Has-A”的關係應使用組合或聚合，如果是“Is-A”關係可使用繼 承。"Is-A"是嚴格的分類學意義上的定義，意思是一個類是另一個類的"一種"；而"Has-A"則不 同，它表示某一個角色具有某一項責任。
2 合成複用原則案例
下面通過一個簡單實例來加深對合成複用原則的理解：
Sunny軟件公司開發人員在初期的CRM系統設計中，考慮到客戶數量不多，系統採用MySQL 作爲數據庫，與數據庫操作有關的類如CustomerDAO類等都需要連接數據庫，連接數據庫的 方法getConnection()封裝在DBUtil類中，由於需要重用DBUtil類的getConnection()方法，設計人 員將CustomerDAO作爲DBUtil類的子類，初始設計方案結構如圖1所示：
![]()
隨着客戶數量的增加，系統決定升級爲Oracle數據庫，因此需要增加一個新的OracleDBUtil類 來連接Oracle數據庫，由於在初始設計方案中CustomerDAO和DBUtil之間是繼承關係，因此在 更換數據庫連接方式時需要修改CustomerDAO類的源代碼，將CustomerDAO作爲OracleDBUtil 的子類，這將違反開閉原則。【當然也可以修改DBUtil類的源代碼，同樣會違反開閉原 則。】
現使用合成複用原則對其進行重構。
根據合成複用原則，我們在實現複用時應該多用關聯，少用繼承。因此在本實例中我們可以 使用關聯複用來取代繼承複用，重構後的結構如圖2所示：
在圖2中，CustomerDAO和DBUtil之間的關係由繼承關係變爲關聯關係，採用依賴注入的方式 將DBUtil對象注入到CustomerDAO中，可以使用構造注入，也可以使用Setter注入。如果需要 對DBUtil的功能進行擴展，可以通過其子類來實現，如通過子類OracleDBUtil來連接Oracle數 據庫。由於CustomerDAO針對DBUtil編程，根據里氏代換原則，DBUtil子類的對象可以覆蓋 DBUtil對象，只需在CustomerDAO中注入子類對象即可使用子類所擴展的方法。例如在 CustomerDAO中注入OracleDBUtil對象，即可實現Oracle數據庫連接，原有代碼無須進行修改，而且還可以很靈活地增加新的數據庫連接方式。
3 設計模式的七大原則
【設計模式】單一職責原則
【設計模式】開閉原則
【設計模式】里氏替換原則
【設計模式】依賴倒轉原則
【設計模式】接口隔離原則
【設計模式】合成複用原則