? ? ? ?繼承是實現代碼重用的有力手段，但并非總是最好的選擇。因為對于普通的具體類進行跨超包邊界的繼承則是非常危險的，它打破了封裝性。子類信賴于其超類中特定功能的實現細節。超類的實現有可能會隨著發行版本的不同而有變化，子類有可能會被破壞。下面是一個例子，擴展HashSet，記錄HashSet實例創建以來一共進行了多少次添加元素的操作。

public class InstrumentedHashSet<E> extends HashSet<E> {

? private static final long serialVersionUID = 678508745042560741L;
? ?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 class Test {
? ?public static void main(String[] args) {
? ? ? ?InstrumentedHashSet<String> s = new InstrumentedHashSet<String>();
? ? ? ?s.add("1");
? ? ? ?System.out.println(s.getAddCount());
? ? ? ?s.add("2");
? ? ? ?System.out.println(s.getAddCount());
? ? ? ?s.add("3");
? ? ? ?System.out.println(s.getAddCount());
? ? ? ?s.addAll(Arrays.asList("Snap", "Crackle", "Pop"));
? ? ? ?System.out.println(s.getAddCount());
? ?}
}

結果：1；2；3；9

? ? ? ?導致上述問題的原因是因為在HashSet內部，addAll方法是基于add方法來實現的,為了修改這個問題，可以去掉被覆蓋的addAll方法，但是它的功能正確性需要信賴于HashSet的addAll方法是在add方法上實現的這一事實，這種自用性（self-use）是實現細節，而不是承諾，不能保證在java平臺的所有實現中都保持不變，不能保證隨著上發行版本的不同而不發生變化。因此，這樣得到的子類將是非常脆弱的。

? ? ? ?導致子類脆弱的原因是，如果父類增加或者移除方法也會對子類產生影響。比如說，子類擴展了某個集合類，覆蓋了所有添加元素的方法，在添加元素之前對元素進行檢查，讓所有元素滿足某個條件。如果在后來的版本中，父類增加了新的添加元素的方法，而子類沒有覆蓋該方法，導致非法元素添加到集合中。那么如果我們只是在子類中對父類進行功能擴展卻不重寫父類的方法呢？，這樣也有可能出現問題。即便父類的實現沒有問題，但也可以因為子類實現不當而破壞父類的約束。比如，父類在后續版本中恰好增加了和子類相同簽名和返回類型的方法。

? ? ? ?使用“復合”方案可以避免以上的所有問題。不用擴展現有的類，而是在新的類中增加一個私有對象，它引用現有對象的一個實例，這種設計被稱作為復合，因為現有的類變成了新類的一個組件，新類中的每個實力方法都可以調用被包涵的現有類實例中對應的方法，并返回它的結果，這稱為轉發，新類中的方法被稱為轉發方法。這樣得到的類將會非常穩固。它不信賴于現有類的實現細節。即使現有的類增加了新方法，也不會影響到新類。這種實現包含了兩部分：類本身和可重用的轉發類，包含了所有的轉發方法，沒有其他方法。

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

public class InstrumentedHashSet<E> extends ForwardingSet<E> {

? ?private int addCount = 0;

? ?public InstrumentedHashSet(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;
? ?}
}

? ? ? ?Set接口的存在使得InstrumentedSet類的設計成為可能，因為Set接口保存了HashSet類的功能特性。除了獲得健壯性外，這種設計也帶來了靈活性。InstrumentedSet類實現了Set接口，并擁有單個構造器，它的參數也是Set類型，從本質上來將，這個類把一個Set轉變成了另一個Set，同時增加了計數的功能。前面提到的基于繼承的方法只適用與單個具體的類，并且對于超類中所支持的每個構造器都要求有一個單獨的構造器，于此不同的是這里的包裝類可以用來包裝任何Set實現，并且可以結合任何以前存在的構造器一起工作。例如：

? ? ? ?Set<Date> s = new InstrumentedHashSet<Date>(new TreeSet<Date>());
? ? ? ?Set<E> s2 = new InstrumentedHashSet<E>(new HashSet<E>());

? ? ? ?因為每一個InstrumentedSet實例都把另一個Set實例包裝起來了，所有InstrumentedSet類被稱為包裝類。這也正是裝飾器模式，因為InstrumentedSet類對一個集合進行了裝飾，為它增加了計數特性。有的時候，復合和轉發的結合被錯誤的稱為"委托"。從技術的角度來說，這不是委托，除非包裝對象把自身傳遞給被包裝的對象。

? ? ? 包裝類幾乎沒有什么缺點。需要注意的一點是，包裝類不適合用在回調框架上，在回調框架中，對象把自身的引用傳遞給其他的對象，用于后續的調用。因為被包裝起來的對象并不知道它外面的包裝對象，所以它傳遞一個指向自身的引用(this)，回調時避開了外面的包裝對象。
? ? ? ?只有當子類真正是超類的子類型(subtype)時，才適合用繼承。對于兩個類A和B，只有當兩者之間確實存在"is-a"的關系的時候，類B才應該擴展A。如果打算讓類B擴展類A，就應該確定一個問題：B確實也是A嗎？如果不能確定答案是肯定的，那么B就不應該擴展A。如果答案是否定的，通常情況下B應該包含A的一個私有實例，并且暴露一個較小的、較簡單的API：A本質上不是B的一部分，只是它的實現細節而已(使用API的客戶端無需知道)。
? ? ? ?如果在適合于使用復合的地方使用了繼承，則會不必要地暴露實現細節。這樣得到的API會把你限制在原始的實現上。永遠限定了類的性能。更為嚴重的是，由于暴露了內部細節，客戶端就有可能直接訪問這些內部細節。這樣至少會導致語言上的混亂。最嚴重的，客戶有可能直接修改超類，從而破壞了子類的約束條件。比如說Properties的實例，設計者的意圖是只允許字符串作為鍵和值，但是如果直接去訪問它的超類Hashtable就可以違反這個約束。

? ? ? ?在決定使用繼承而不是復合之前，還應該問自己最后一組問題：對于你正試圖擴展的類，它的API中有沒有缺陷呢？如果有，你是否愿意把它們傳播到類的API中？繼承機制會把超類API中的所有缺陷傳播到子類中(除非你愿意重寫一遍改進版的超類)，而復合則允許設計親的API來隱藏這些細節。

? ? ? 簡而言之，繼承的功能非常強大，但是也存在諸多問題，因為它違反了封裝原則。只有當子類和超類之間確實存在子類型的關系時，使用繼承才是恰當的。即使如此，如果子類和超類處在不同的包中，并且超類并不是為了繼承而設計的，那么繼承將會導致脆弱性。為了避免這種情況，可以使用復合和轉發機制來代替繼承，尤其是當存在適當的接口可以實現包裝類的時候。包裝類不僅比子類更加健壯，而且功能也更強大。