mirror of
https://github.com/Jueee/effective-Java.git
synced 2026-08-19 08:23:30 +08:00
39 lines
4.6 KiB
Markdown
39 lines
4.6 KiB
Markdown
## 组合优于继承
|
||
|
||
继承是实现代码重用的有效方式，但并不总是最好的工具。
|
||
|
||
从普通的具体类跨越包级边界继承，是危险的。
|
||
|
||
**与方法调用不同，继承打破了封装。**
|
||
|
||
换句话说，一个子类依赖于其父类的实现细节来保证其正确的功能。 父类的实现可能会从发布版本不断变化，如果是这样，子类可能会被破坏，即使它的代码没有任何改变。 因此，一个子类必须与其超类一起更新而变化，除非父类的作者为了继承的目的而专门设计它，并对应有文档的说明。
|
||
|
||
查询 `HashSet` ，从创建它之后已经添加了多少个元素：
|
||
|
||
- [Item18Example01.java](ClassesAndInterfaces/src/main/java/com/jueee/item18/Item18Example01.java)：不满足预期
|
||
|
||
`HashSet` 类包含两个添加元素的方法，分别是 `add` 和 `addAll`，所以重写这两个方法。
|
||
|
||
- [Item18Example02.java](ClassesAndInterfaces/src/main/java/com/jueee/item18/Item18Example02.java)：满足预期
|
||
|
||
因为 `HashSet` 的 `addAll` 方法是在其 `add` 方法之上实现的。通过消除 `addAll` 方法的重写来“修复”子类。
|
||
|
||
导致子类脆弱的一个相关原因是，它们的父类在后续的发布版本中可以添加新的方法。假设一个程序的安全性依赖于这样一个事实：所有被插入到集中的元素都满足一个先决条件。可以通过对集合进行子类化，然后并重写所有添加元素的方法，以确保在添加每个元素之前满足这个先决条件，来确保这一问题。如果在后续的版本中，父类没有新增添加元素的方法，那么这样做没有问题。但是，一旦父类增加了这样的新方法，则很有可能由于调用了未被重写的新方法，将非法的元素添加到子类的实例中。这不是个纯粹的理论问题。在把 `Hashtable` 和 `Vector` 类加入到 `Collections` 框架中的时候，就修复了几个类似性质的安全漏洞。
|
||
|
||
这两个问题都源于重写方法。 如果仅仅添加新的方法并且不要重写现有的方法，可能会认为继承一个类是安全的。 虽然这种扩展更为安全，但这并非没有风险。 如果父类在后续版本中添加了一个新的方法，并且你不幸给了子类一个具有相同签名和不同返回类型的方法，那么你的子类编译失败。 如果已经为子类提供了一个与新的父类方法具有相同签名和返回类型的方法，那么你现在正在重写它，因此将遇到前面所述的问题。 此外，你的方法是否会履行新的父类方法的约定，这是值得怀疑的，因为在你编写子类方法时，这个约定还没有写出来。
|
||
|
||
幸运的是，有一种方法可以避免上述所有的问题。不要继承一个现有的类，而应该给你的新类增加一个私有属性，该属性是 现有类的实例引用，这种设计被称为组合（composition），因为现有的类成为新类的组成部分。新类中的每个实例方法调用现有类的包含实例上的相应方法并返回结果。这被称为转发（forwarding），而新类中的方法被称为转发方法。由此产生的类将坚如磐石，不依赖于现有类的实现细节。
|
||
|
||
通过组合方式实现：
|
||
|
||
- [ForwardingSet.java](ClassesAndInterfaces/src/main/java/com/jueee/item18/ForwardingSet.java)：新类中的每个实例方法调用现有类的包含实例上的相应方法并返回结果。
|
||
|
||
- [InstrumentedSet.java](ClassesAndInterfaces/src/main/java/com/jueee/item18/InstrumentedSet.java)：包装类，因为每个 `InstrumentedSet` 实例都包含（“包装”）另一个 Set 实例。
|
||
|
||
这也被称为装饰器模式，因为 `InstrumentedSet` 类通过添加计数功能来“装饰”一个集合。
|
||
|
||
- [Item18Example03.java](ClassesAndInterfaces/src/main/java/com/jueee/item18/Item18Example03.java)：测试组合方式实现的。
|
||
|
||
如果在合适组合的地方使用继承，则会不必要地公开实现细节。由此产生的 API 将与原始实现联系在一起，永远限制类的性能。更严重的是，通过暴露其内部，客户端可以直接访问它们。至少，它可能导致混淆语义。
|
||
|
||
总之，继承是强大的，但它是有问题的，因为它违反封装。 只有在子类和父类之间存在真正的子类型关系时才适用。 即使如此，如果子类与父类不在同一个包中，并且父类不是为继承而设计的，继承可能会导致脆弱性。 为了避免这种脆弱性，使用合成和转发代替继承，特别是如果存在一个合适的接口来实现包装类。 包装类不仅比子类更健壮，而且更强大。 |