合成聚合复用原则

Java语言API中的例子
在Java语言的API中，有几个明显违 反这一原则的例子，其中最著名的就是 Stack和Properties。 在此，以后者为例阐述： Properties被不恰当的设置成 Hashtable子类，如下图所示：
Dictionary Map Colneable Java.io.Serializable Java.util. Hashtable
Baidu Nhomakorabea
一个类是另一个类的一个角色
人 角色
雇员
经理
学生
与里氏代换原则联合使用
里氏代换原则是继承复用的基石。只有当 衍生类可以替换掉基类，软件单位的功能不会受 到影响时，基类才真正被复用，而衍生类也才能 够在基类的基础上增加新的功能。 如果两个类的关系是“Has-A”而不是“IsA”关系，这两个类一定违反里氏代换原则。 只有两个类满足里氏代换原则，才有可能 是“Is-A”关系。
Java.util. Properties
一个性质列（ Properties ）不是一个 Hashtable。此时，使用聚合比使用继承 关系更为合适。 我们可以看一下如下情况：
不恰当处
1.由于Properties继承了Hashtable行为，因而 当p是一个Properties类型的对象时， p.getProperties(key)与p.get(key)就会给出 不同的结果。 2.客户端可以通过类型的转换，直接使用超类型 的行为。 3.客户端可以通过Hashtable提供的行为加入任 意类型的键和值。绕过Properties接口，并导致 Properties的内部矛盾和崩溃。
合成/聚合复用主要缺点
通过这种复用建造的系统会有较多的对 象需要管理。
通过继承达到复用的目的
合成/聚合作为复用手段可以应用到 几乎任何环境中去，而继承只能在有限的 环境中使用。尽管继承是一种非常重要的 复用手段，但应当首先考虑合成/聚合，而 / 不是继承。
继承复用优点：
新的实现较为容易，因为超类的大部分功 能可以通过继承的关系自动进入子类。 修改和扩展继承而来的实现较为容易。
在对违反里氏代换原则的设计进行重 构时，有两种方法： 一是加入一个抽象超类； 二是将继承改为合成/聚合的关系。
里氏代换原则（LSP）
一个软件实体如果适用于一个基类的 话，那么一定适用于其子类，而且它根本 不能察觉出基类对象和子类对象的区别。
区分“Is-A”和 “Has-A”
Is-A”代表一个类是另外一个类的一种 “Has-A”代表一个类是另一个类的一个角 色，而不是另一个类的特殊种类。 对于"Is-A"应该考虑使用继承，而 "Has-A"使用合成/聚合。
合成和聚合均是关联的特殊种类。 聚合：“拥有”关系或整体与部分的关系； 是引用的聚合 合成：一种强得多的“拥有”关系； 是值的聚合
关于合成关系
其部分和整体的生命周期是一样的。 一个合成的新对象完全拥有对其组成成分 的支配权，包括它们的创建和销毁等。 更进一步讲，一个合成关系中的成员 对象是不能与另一个合成对象共享的。如 果一个合成关系销毁了，那么所有的成员 对象要么自己销毁所有的成员对象（较普 遍），要么就得将这一责任交给别的对象 （较罕见）。
复用的基本种类
在面向对象的设计里，有两种基本的 方法可以在不同的环境中复用已有的设计 和实现，即通过合成/聚合或继承。 那么此两种方法在可维护性上面有何 区别呢？
合成/聚合复用
好处
新对象存取成分对象的唯一方法是通过成分对象 的接口。 这种复用是黑箱复用，因为成分对象的内部细节 是新对象所看不见的。 这种复用支持包装。 这种复用所需的依赖较少。 这种复用可以在运行时间内动态进行，新对象可 以动态的引用与成分对象类型相同的对象。
继承复用缺点
继承复用破坏包装，因为继承将超类的实现细节 暴露给子类。由于超类的内部细节常常是对于子 类透明的，所以这种复用是透明的复用，又称 “白箱”复用。 如果超类发生改变，那么子类的实现也不得不发 生改变。 从超类继承而来的实现是静态的，不可能在运行 时间内发生改变，没有足够的灵活性。
从代码重构的角度理解
面向对象设计方法
L07 B 合成/聚合复用原则(CAPP) wxz
概要
合成、聚合复用原则就是在一个新的 对象里面使用一些已有的对象，使之成为 新对象的一部份，新的对象通过向这些对 象的委派达到复用已有功能的目的。 这个原则有一个简短的描述：要尽量 使用合成、聚合，尽量不要使用继承。
合成、聚合的区别