以下内容来自《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 设计模式的七大原则
【设计模式】单一职责原则
【设计模式】开闭原则
【设计模式】里氏替换原则
【设计模式】依赖倒转原则
【设计模式】接口隔离原则
【设计模式】合成复用原则
【设计模式】迪米特法则
