原文链接
文章也上传到
（欢迎关注，欢迎大神提点。）
ITEM 18 重组合，轻继承
继承是实现代码重用的有效方法，但是使用的不恰当的话就会导致软件变得脆弱。在一个包里使用继承是安全的，这里子类和父类都由同一个程序员控制。在特定的设计和文档说明下使用也是安全的（Item19）。但是跨越包继承就是危险的了。这里说的继承指的是实现继承（一个类extends另外一个类），不包括接口的继承（一个类实现一个接口或一个接口继承另一个接口）。
继承破坏了封装性。换句话说，子类过于依赖父类的实现细节。然而父类的实现可能随着版本更替而发生改变，这时候子类就算没有任何改动也可能会崩溃。结果就是：子类必须随着父类的变化而变化，除非父类的作者有文档说明或者这个类本身就是用来继承的。
举个例子，假如我们有个程序使用HashSet，我们需要计算一共添加到这个HashSet多少个元素（当删除元素时，会减少标志）。为了实现这个需求，我们给HashSet添加一个计数变量并提供一个getter方法返回这个变量的值。已知的是HashSet类有两个方法可以添加元素，add和addAll。所以我们重写这些方法：
//不恰当的使用继承例子
public class InstrumentedHashSet<E> extends HashSet<E> {
// The number of attempted element insertions
private int addCount = 0;
public InstrumentedHashSet() {
}
public InstrumentedHashSet(int initCap, float loadFactor) {
super(initCap, loadFactor);
}
@Override public boolean add(E e) {
addCount++;
return super.add(e);
}
@Override public boolean addAll(Collection<? extends E> c) {
addCount += c.size();
return super.addAll(c);
}
public int getAddCount() {
return addCount;
}
}
这个例子看着没啥问题，但是却是不能正常工作的。假设我们创建一个实例然后使用addAll给它添加3个元素。（顺便提一句，Java9中我们创建一个list可使用静态工厂方法List.of，之前我们使用的是Arrays.asList）:
InstrumentedHashSet<String> s = new InstrumentedHashSet<>();
s.addAll(List.of("Snap", "Crackle", "Pop"));
然后我们调用getAddCount方法获取结果，发现结果不是3而是6。难道我们哪里写错了么？
原来在HashSet内部，addAll方法会调用自己的add方法。所以每个元素被加了两次。
我们可以修复这个问题通过移除addAll方法，虽然这么做可以修复这个问题，但是这样的做法的前提是建立在HashSet的addAll方法调用了内部add方法的基础上。而这个前提并不能保证随着Java版本的更替不会被改变。因此，InstrumentedHashSet这个类就变的很脆弱了。
有一种稍微更好点的做法是重写addAll方法的实现，使用迭代器把每一个元素使用add方法添加到指定的collection中，这样的话不管原来addAll方法有没有调用add都没关系了，因为现在不会调用父类的addAll的实现了。然而，这样还是没有解决我们所有的问题。因为这时候当父类中如果存在调用自己的addAll将会出问题，而且可能会导致方法更耗时，降低性能等等。另外，这些方法有时候会被设置成private的，也不总是会允许子类重写。如果父类在之后的版本中增加新的方法来添加元素也将导致子类出问题，因为此时子类没有在新方法中实现自己的计数功能。当Hashtable和Vector被升级进入Collections Framework时类似的安全漏洞必须被修复。
这些问题都源于overriding 方法。你可能会想继承一个类仅仅添加新的方法而不重写就是安全的。确实这样会更加安全一点，但是也不是没有一点风险，如果父类在之后的版本中添加了一个和你同名但返回值不同的方法，那么你的类将编译不通过。如果父类添加了一个和你同名返回值也相同的方法，那就相当于你重写了这个方法，上面说的问题就又出现了。
幸运的是，有一种方法可以避免上面提到的所有问题。不是继承于一个现有的类，而是添加一个对现有类的私有属性，这种设计叫做组合，因为已存在的类成了新类的组件。新类中的这个实例调用现有类相应的方法并返回相应结果，这叫转发。因为新类不依赖于现有类的实现细节，所以会变得相对健壮，不会跟现有类的方法产生冲突。这里提供一种替代InstrumentedHashSet类的实现方法，使用组件和转发方法。注意：这里的实现分成两个类，类本身和一个可重用的转发类，它包含所有要转发的方法：
//包装类
public class InstrumentedSet<E> extends ForwardingSet<E> {
private int addCount = 0;
public InstrumentedSet(Set<E> s) {
super(s);
}
@Override public boolean add(E e) {
addCount++;
return super.add(e);
}
@Override public boolean addAll(Collection<? extends E> c) {
addCount += c.size();
return super.addAll(c);
}
public int getAddCount() {
return addCount;
}
}
//可重用的转发类
public class ForwardingSet<E> implements Set<E> {
private final Set<E> s;
public ForwardingSet(Set<E> s) { this.s = s; }
public void clear() { s.clear(); }
public boolean contains(Object o) { return s.contains(o); }
public boolean isEmpty() { return s.isEmpty(); }
public int size() { return s.size(); }
public Iterator<E> iterator() { return s.iterator(); }
public boolean add(E e) { return s.add(e); }
public boolean remove(Object o) { return s.remove(o); }
public boolean containsAll(Collection<?> c)
{ return s.containsAll(c); }
public boolean addAll(Collection<? extends E> c)
{ return s.addAll(c); }
public boolean removeAll(Collection<?> c)
{ return s.removeAll(c); }
public boolean retainAll(Collection<?> c)
{ return s.retainAll(c); }
public Object[] toArray() { return s.toArray(); }
public <T> T[] toArray(T[] a) { return s.toArray(a); }
@Override public boolean equals(Object o)
{ return s.equals(o); }
@Override public int hashCode() { return s.hashCode(); }
@Override public String toString() { return s.toString(); }
}
InstrumentedSet类基于Set接口实现，该接口包含了HashSet的功能特性。InstrumentedSet类实现了Set接口并提供一个接受Set类型的构造方法。本质上讲，这种实现是将一个Set转换成了另一个，并添加了自己的计数功能。不像继承那样只能提供单一功能而且要求实现父类的一系列构造方法，这个包装类可以实现任何set工具，并可以结合现有的任何构造方法一起使用。
Set<Instant> times = new InstrumentedSet<>(new TreeSet<>(cmp));
Set<E> s = new InstrumentedSet<>(new HashSet<>(INIT_CAPACITY));
InstrumentedSet类甚至可以临时被用于替换没有相应功能的set实例：
static void walk(Set<Dog> dogs) {
InstrumentedSet<Dog> iDogs = new InstrumentedSet<>(dogs);
... // Within this method use iDogs instead of dogs
}
因为每一个InstrumentedSet实例都包含另一个set对象，所以被称为包装类。这也被称为装饰器模式，如InstrumentedSet类用计数方法装饰类set类。有时候来看，组合和转发的结合体非常类似于代理模式。但是只要包装对象没有把自己传递给别的包装对象就不算是代理。
包装类的缺点很少，但有一点是包装类不能被用在回调型的框架中。在包装类中，回调时调用的是对象本身，因为对象发送对自己的引用给其他的对象。这被叫做SELF问题。因为被包装的类不知道谁是它的包装类，所以回调也就避开了包装器。有人担心转发类的性能和内存占用问题，但是实际证明这两者都不会造成太大的问题。写转发类是乏味的，而且你不得不为每一个接口写一次转发类。
只有当一个类的类型真正属于另一个类的时候才适合使用继承。换句话说，就是类B继承于类A时，一定是当“is-A”的时候。如果当你的类B要继承于类A的时候，要问自己：B真的属于A类型么？如果你不能确定，那就不应该使用继承。如果回答是No，那么B应该包含一个类A的私有对象。在Java平台很多地方都违背了这个原则，例如Stack类不属于Vector，但是继承于Vector；同样一个属性list不是一个hash table，但是Perperties继承于HashTable。在这两种情况下，组合都会更好点。
如果在适合使用组合的地方使用了继承，就会暴漏实现细节。会被原始的实现限制住，永远限制了你类的性能。更严重的是，暴漏内部实现是你的客户端（使用者）直接访问到内部。至少，它会导致语意混乱。例如，如果p引用一个Properties对象，然后p.getProperty(key)可能会和p.get(key)产生混乱，因为后者是从Hashtable继承而来的方法。更严重的是，子类可能通过直接修改父类会破环父类的不变性。至于Properties，设计者希望只有String 类型被允许当作keys和values，但是由于继承于Hashtable，父类的put和putAll允许其他类型。一旦在遭到破坏的Properties对象上使用load和store将会不成功。当发现这个问题时也为时以晚，因为已经有很多客户端已经基于这个类使用了非string类型的key和value。如java库中的描述：
* Because <code>Properties</code> inherits from <code>Hashtable</code>, the
* <code>put</code> and <code>putAll</code> methods can be applied to a
* <code>Properties</code> object. Their use is strongly discouraged as they
* allow the caller to insert entries whose keys or values are not
* <code>Strings</code>. The <code>setProperty</code> method should be used
* instead. If the <code>store</code> or <code>save</code> method is called
* on a "compromised" <code>Properties</code> object that contains a
* non-<code>String</code> key or value, the call will fail. Similarly,
* the call to the <code>propertyNames</code> or <code>list</code> method
* will fail if it is called on a "compromised" <code>Properties</code>
* object that contains a non-<code>String</code> key.
当你要使用继承代替组合时，问自己最后一个问题：继承的父类的api有没有瑕疵呢？如果有你是否愿意将这种瑕疵继承到自己的api中？继承会将父类的瑕疵传递下来，而组合可以允许你设计新的api隐藏这些瑕疵。
总结起来，继承是强大的，但是它会造成很多问题，因为它会破坏封装性。它仅适合当子类和父类是is-a的关系时使用。不仅如此，继承还可能导致类的脆弱，假如类继承于不同包的类或父类不是被用于继承设计时。为了避免这种问题，使用组合和转发来代替继承。使用包装类不仅比继承更加健壮而且也更加强大。
