Java 比繼承更好的一種機制 —— 複合

本文結合《Effective Java》第四章條目16《複合優先於繼承》和自己的理解及實踐，講解了Java繼承機制的缺陷和替代方案，文章發佈於專欄Effective Java，歡迎讀者訂閱。

繼承的缺陷

繼承的缺陷是由它過於強大的功能所導致的。繼承使得子類依賴於超類的實現，從這一點來說，就不符合封裝的原則。

一旦超類隨着版本的發佈而有所變化，子類就有可能遭到破壞，即使它的代碼完全沒有改變。

爲了說明的更加具體，假設我們現在程序中使用到了HashSet，我們需要增加一個功能，去統計這個HashSet自創建以來一共曾經添加過多少元素。

在還不知道繼承的缺陷的情況下，我們設計了一個類，繼承了HashSet，添加了一個屬性addCount來進行統計，並且複寫了add和addAll方法，在方法裏面修改addCount的值，代碼如下：

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;
    }

}

這個類看起了合情合理，但是它並不能正常工作，執行這段代碼：

    public static void main(String[] args) {
        InstrumentedHashSet<String> s =
            new InstrumentedHashSet<String>();
        s.addAll(Arrays.asList("Snap", "Crackle", "Pop"));    
        System.out.println(s.getAddCount()); // expect 3 but 6
    }

因爲只插入了三個元素，我們期望getAddCount方法應該返回3，然後事實卻是返回6，哪裏出錯了？

其實，在HashSet內部，addAll方法是基於add方法來實現的，因此，使用addAll添加三個元素，會調用一次addAll，三次add。

再看看我們複寫的方法，也就明白爲什麼getAddCount返回6了。

當然，你會說，既然HashSet是這樣實現的，那麼我們就不要複寫addAll方法就行了。是的，沒錯。

但是這樣雖然可以正常工作，但是它的正確性卻依賴於這樣的事實：HashSet的addll方法是在add方法上實現的。

一旦超類修改了實現細節，我們的功能就會有可能受影響。

總的來說，繼承存在三個天然缺陷，這些缺陷會導致軟件非常脆弱：

1） 子類如果調用了父類的方法，那麼就會對父類形成依賴，一旦父類做了改動，子類就很可能不能正常工作。

2） 如果父類新增了方法，而子類恰好已經提供了一個簽名相同但是返回值不同的方法，那麼子類將無法通過編譯。

3） 在不應該繼承的時候使用繼承，會暴露不必要的API給子類。這一點，Java平臺就犯過錯，典型的例子就是Properties繼承了HashTable，這是不合理的，屬性列表不是散列表，但是Java代碼裏的Properties卻繼承了HashTable，導致用戶創建Properties實例後，有put和setProperties兩個方法，有get和getProperties兩個方法，而put和get方法是不應該給用戶暴露的。

因爲在Properties裏，key和value都應該是String，而HashMap可以是其他類型甚至是對象。

public class TestProperty {
	public static void main(String[] args) {
		Properties properties = new Properties();
		properties.setProperty("aaa", "aaa");
		properties.put("aaa", new TestPropertyObj());
		System.out.println(properties.getProperty("aaa")); // null
		System.out.println(properties.get("aaa")); // com.hzy.effjava.chp3.item16.TestProperty$TestPropertyObj@5f4fcc96
	}
	static class TestPropertyObj {
		
	}
}

複合  繼承的替代方案

上一節講了繼承的缺陷，這一節就讓我們來看看解決這個問題的方案——複合。

首先我們需要一個持有Set對象的一個類，這個類實現了Set接口，實現方法裏調用了所持有的Set對象的對應的方法，因此我們也叫它轉發類：

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(); }
}

接着，我們就可以設計具有統計功能的類了，只需要去繼承我們剛剛創建的轉發類，然後統計的邏輯代碼的編寫即可：

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 static void main(String[] args) {
        InstrumentedSet<String> s =
            new InstrumentedSet<String>(new HashSet<String>());
        s.addAll(Arrays.asList("Snap", "Crackle", "Pop"));    
        System.out.println(s.getAddCount());
    }
}

這樣的實現方式，避免了上一節講的所有問題，由於不使用繼承，它不依賴於超類的實現邏輯，也不用擔心超類新增新的方法對我們的影響。

而且這樣寫還有一個好處，這個類可以給所有實現了Set接口的類添加統計功能，而不僅僅是HashSet，還包括TreeSet等其他Set。

其實，這就是裝飾模式，InstrumentedSet對Set進行了修飾，給它增加了計數屬性。

總結

繼承會破壞類的封裝性，導致子類非常脆弱，容易受到破壞。

使用複合的方式，對超類進行修飾，使得子類更加的健壯，同時功能更加強大。