复合优于继承

• 问题
  当通过子类继承父类并不是代码重用的最好手段，有这样的缺点：
  1. 与方法调用不同的是，继承打破封装性。子类依赖于父类，如果父类的具体实现细节改变，子类也会跟着相应改变。除非父类就是专门为扩展而设计的，并且有良好的文档说明；
  2. 父类方法中的”自用性“问题，导致的子类方法逻辑出错，比如统计HashSet自创建以来插入了多少个元素，需要覆盖add()方法和addAll()方法：

public class TestHashSet<E> extends HashSet<E> {
    private int count = 0;

    public TestHashSet(int initCap, float loadFactor) {
        super(initCap, loadFactor);
    }

    @Override
    public boolean add(E e) {
        count++;
        return super.add(e);
    }

    @Override
    public boolean addAll(Collection<? extends E> c) {
        count += c.size();
        return super.addAll(c);
    }

    public int getCount() {
        return count;
    }

    public static void main(String[] args) {
        TestHashSet<String> hashSet = new TestHashSet<String>(16, 0.75f);
        hashSet.addAll(Arrays.asList(new String[]{"1","2","3"}));
        System.out.println(hashSet.getCount());
    }
}

按照预想的会打印输出3，但实际上打印输出6。这是因为，addAll()方法内部实现调用了add()方法，因此总共的次数就是3+3=6。这种情况就是父类方法中”自用性“导致的。那么，针对由继承带来的问题应该如何解决？

• 解决
  针对继承带来的问题，可以采用复合的方式进行解决，即不用扩展现有的类，而是在新的类中增加一个私有域，它引用现有类的一个实例。因此现有类变成了一个新类的一个组件，新类中的每个实例方法就可以调用被包含的类的实例方法，并返回相应的结果，这称之为转发。

采用复合/转发的方式重写上面的TestHash，包含了两个部分：新类本身以及被包含的转发类：

// Wrapper class - uses composition in place of inheritance
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;
    }
}
// Reusable forwarding class
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(); }
}

在上面这个例子里构造了两个类，一个是用来扩展操作的包裹类，一个是用来与现有类进行交互的转发类，可以看到，在现在这个实现中包裹类不再直接扩展Set，而是扩展了他的转发类，而在转发类内部，现有Set类是作为它的一个数据域存在的，转发类实现了Set接口，这样它就包括了现有类的基本操作。每个转发动作都直接调用现有类的相应方法并返回相应结果。这样就将信赖于Set的实现细节排除在包裹类之外。有的时候，复合和转发的结合被错误的称为"委托(delegation)"。从技术的角度来说，这不是委托，除非包装对象把自身传递给被包装的对象。

• 什么时候使用继承？
  只有当子类真正是超类的子类型(subtype)时，才适合用继承。对于两个类A和B，只有当两者之间确实存在"is-a"的关系的时候，类B才应该扩展A。如果打算让类B扩展类A，就应该确定一个问题：B确实也是A吗？如果不能确定答案是肯定的，那么B就不应该扩展A。如果答案是否定的，通常情况下B应该包含A的一个私有实例，并且暴露一个较小的、较简单的API：A本质上不是B的一部分，只是它的实现细节而已(使用API的客户端无需知道)。

• 总结
  简而言之，继承的功能非常强大，但是也存在诸多问题，因为它违反了封装原则。只有当子类和超类之间确实存在子类型的关系时，使用继承才是恰当的。即使如此，如果子类和超类处在不同的包中，并且超类并不是为了继承而设计的，那么继承将会导致脆弱性。为了避免这种情况，可以使用复合和转发机制来代替继承，尤其是当存在适当的接口可以实现包装类的时候。包装类不仅比子类更加健壮，而且功能也更强大。