EffectiveJava——复合优先于继承

继承时实现代码重用的重要手段，但它并非永远是完成这项工作的最佳工具，不恰当的使用会导致程序变得很脆弱，当然，在同一个程序员的控制下，使用继承会变的非常安全。想到了很有名的一句话，你永远不知道你的用户是如何使用你写的程序的，一个程序员继承另一个程序员写的类也是同样的危险。

于方法调用不同的是，继承打破的封装性。换句话说，子类依赖于其超类中特定功能的实现细节。超类的实现有可能随着发行版本的不同而变化，如果真的发生了变化，子类可能会遭到破坏，即使它的代码完全没有修改过。因而，子类有必要随着超类的更新而演变。

为了说明的更加具体一些，假设有一个程序使用了HashSet，想要查询它被创建以来添加了多少个元素，编写一个hashSet变量，它记录下试图插入的元素数量，并有一个访问数量的方法

/**
 * 复合优先与继承
 * @author weishiyao
 *
 * @param <E>
 */
// Broken - Inappropriate use of inheritance
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方法添加三个元素，

	public static void main(String[] args) {
		InstrumentedHashSet<String> s = new InstrumentedHashSet<>();
		s.addAll(Arrays.asList("a", "b", "c"));
		System.out.println(s.getAddCount());
	}

　　这时候我们期望的返回值应该是3，但是事与愿违，结果是6，因为在HashSet内部，addAll方法是机遇add方法来实现，相当于每次插入我们都计算了2次，所以结果是6.

　　这个问题来源于Override这个动作，但是如果我们不覆盖现有的方法，可能认为是安全的，虽然这种做法比较安全一些，但是，也并非没有风险，如果超类在后续版本中增加了一个新的方法，并且不幸的是，这个方法如果和我们写的方法重名，要么是返回类型不同，这样整个程序将会直接down掉，如果返回类型相同，问题返回上面。

　　这时候有一种方案可以避免以上的所有问题。不用扩展现有的类，而是在新的类中增加一个私有对象，它引用现有对象的一个实例，这种设计被称作为复合，因为现有的类变成了新类的一个组件，新类中的每个实力方法都可以调用被包涵的现有类实例中对应的方法，并返回它的结果，这称为转发，新类中的方法被称为转发方法。

　　重新实现上面那个需求

/**
 * 复合优先与继承
 * @author weishiyao
 *
 * @param <E>
 */
// Reusable forwarding class
public class ForwardingSet<E> implements Set<E> {

	private final Set<E> s;

	public ForwardingSet(Set<E> s) {
		this.s = s;
	}

	@Override
	public int size() {
		return s.size();
	}

	@Override
	public boolean isEmpty() {
		return s.isEmpty();
	}

	@Override
	public boolean contains(Object o) {
		return s.contains(o);
	}

	@Override
	public Iterator<E> iterator() {
		return s.iterator();
	}

	@Override
	public Object[] toArray() {
		return s.toArray();
	}

	@Override
	public <T> T[] toArray(T[] a) {
		return s.toArray(a);
	}

	@Override
	public boolean add(E e) {
		return s.add(e);
	}

	@Override
	public boolean remove(Object o) {
		return s.remove(o);
	}

	@Override
	public boolean containsAll(Collection<?> c) {
		return s.containsAll(c);
	}

	@Override
	public boolean addAll(Collection<? extends E> c) {
		return s.addAll(c);
	}

	@Override
	public boolean retainAll(Collection<?> c) {
		return s.retainAll(c);
	}

	@Override
	public boolean removeAll(Collection<?> c) {
		return s.removeAll(c);
	}

	@Override
	public void clear() {
		s.clear();
	}

}

　　

/**
 * 复合优先与继承
 * @author weishiyao
 *
 * @param <E>
 */
// 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++;
		return super.addAll(c);
	}

	public int getAddCount() {
		return addCount;
	}
}

　　Set接口的存在使得InstrumentedSet类的设计成为可能，因为Set接口保存了HashSet类的功能特性。除了获得健壮性外，这种设计也带来了灵活性。InstrumentedSet类实现了Set接口，并拥有单个构造器，它的参数也是Set类型，从本质上来将，这个类把一个Set转变成了另一饿Set，同时增加了计数的功能。

　　前面提到的基于继承的方法只适用与单个具体的类，并且对于超类中所支持的每个构造器都要求有一个单独的构造器，于此不同的是这里的包装类可以用来包装任何Set实现，并且可以结合任何以前存在的构造器一起工作。例如：

Set<Date> s1 = new InstrumentedSet<>(new TreeSet<Date>());
Set<E> s2 = new InstrumentedSet<E>(new HashSet<E>());

　　因为每一个InstrumentedSet实例都把另一个Set实例包装起来了，所有InstrumentedSet类被称为包装类。这也正是装饰器模式，因为InstrumentedSet类对一个集合进行了装饰，为它增加了计数特性。