原文：http://blog.csdn.Net//softwarezhang/archive/2005/04/25/362832.ASPx
大多數好的設計者象躲避瘟疫一樣來避免使用實現繼承(extends 關系)。實際上80%的代碼應該完全用interfaces寫，而不是通過extends。“Java設計模式”一書詳細闡述了怎樣用接口繼承代替實現繼承。這篇文章描述設計者為什麼會這麼作。
Extends是有害的；也許對於Charles Manson這個級別的不是，但是足夠糟糕的它應該在任何可能的時候被避開。“Java設計模式”一書花了很大的部分討論用interface繼承代替實現繼承。
好的設計者在他的代碼中，大部分用interface，而不是具體的基類。本文討論為什麼設計者會這樣選擇，並且也介紹一些基於interface的編程基礎。
接口（Interface）和類（Class）?
一次，我參加一個Java用戶組的會議。在會議中，Jams Gosling（Java之父）做發起人講話。在那令人難忘的Q&A部分，有人問他：“如果你重新構造Java，你想改變什麼？”。“我想拋棄classes”他回答。在笑聲平息後，它解釋說，真正的問題不是由於class本身，而是實現繼承(extends 關系)。接口繼承（implements關系）是更好的。你應該盡可能的避免實現繼承。
失去了靈活性
為什麼你應該避免實現繼承呢？第一個問題是明確的使用具體類名將你固定到特定的實現，給底層的改變增加了不必要的困難。
在當前的敏捷編程方法中，核心是並行的設計和開發的概念。在你詳細設計程序前，你開始編程。這個技術不同於傳統方法的形式----傳統的方式是設計應該在編碼開始前完成----但是許多成功的項目已經證明你能夠更快速的開發高質量代碼，相對於傳統的按部就班的方法。但是在並行開發的核心是主張靈活性。你不得不以某一種方式寫你的代碼以至於最新發現的需求能夠盡可能沒有痛苦的合並到已有的代碼中。
勝於實現你也許需要的特征，你只需實現你明確需要的特征，而且適度的對變化的包容。如果你沒有這種靈活，並行的開發，那簡直不可能。
對於Inteface的編程是靈活結構的核心。為了說明為什麼，讓我們看一下當使用它們的時候，會發生什麼。考慮下面的代碼：
f()
{ LinkedList list = new LinkedList();
//...
g( list );
}
g( LinkedList list )
{
list.add( ... );
g2( list )
}
現在，假設一個對於快速查詢的需求被提出，以至於這個LinkedList不能夠解決。你需要用HashSet來代替它。在已有代碼中，變化不能夠局部化，因為你不僅僅需要修改f()也需要修改g()（它帶有LinkedList參數），並且還有g()把列表傳遞給的任何代碼。象下面這樣重寫代碼:
f()
{ Collection list = new LinkedList();
//...
g( list );
}
g( Collection list )
{
list.add( ... );
g2( list )
}
這樣修改Linked list成hash，可能只是簡單的用new HashSet()代替new LinkedList()。就這樣。沒有其他的需要修改的地方。
這個代碼成功編譯，但是因為基類不知道關於stack指針堆棧的情況,這個stack對象當前在一個未定義的狀態。下一個對於push（）調用把新的項放入索引2的位置。（stack_pointer的當前值），所以stack有效地有三個元素-下邊兩個是垃圾。（Java的stack類正是有這個問題，不要用它）.
對這個令人討厭的繼承的方法問題的解決辦法是為Stack覆蓋所有的ArrayList方法，那能夠修改數組的狀態，所以覆蓋正確的操作Stack指針或者拋出一個例外。(removeRange()方法對於拋出一個例外一個好的候選方法)。
這個方法有兩個缺點。第一，如果你覆蓋了所有的東西，這個基類應該真正的是一個interface，而不是一個class。如果你不用任何繼承方法，在實現繼承中就沒有這一點。第二，更重要的是，你不能夠讓一個stack支持所有的ArrayList方法。例如，令人煩惱的removeRange()沒有什麼作用。唯一實現無用方法的合理的途徑是使它拋出一個例外，因為它應該永遠不被調用。這個方法有效的把編譯錯誤成為運行錯誤。不好的方法是，如果方法只是不被定義，編譯器會輸出一個方法未找到的錯誤。如果方法存在，但是拋出一個例外，你只有在程序真正的運行時，你才能夠發現調用錯誤。
對於這個基類問題的一個更好的解決辦法是封裝數據結構代替用繼承。這是新的和改進的Stack的版本：
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{
the_data.add( stack_poniter++, article );
}
public Object pop()
{
return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{
for（ int i = 0; i < o.length; ++i ）
push( articles[i] );
}
}
到現在為止，一直都不錯，但是考慮脆弱的基類問題，我們說你想要在stack創建一個變量， 用它在一段周期內跟蹤最大的堆棧尺寸。一個可能的實現也許象下面這樣:
class Monitorable_stack extends Stack
{
private int high_water_mark = 0;
private int current_size;
public void push( Object article )
{
if( ++current_size > high_water_mark )
high_water_mark = current_size;
super.push( article );
}
publish Object pop()
{
--current_size;
return super.pop();
}
public int maximum_size_so_far()
{
return high_water_mark;
}
}
這個新類運行的很好，至少是一段時間。不幸的是，這個代碼發掘了一個事實，push_many()通過調用push()來運行。首先，這個細節看起來不是一個壞的選擇。它簡化了代碼，並且你能夠得到push()的派生類版本，甚至當Monitorable_stack通過Stack的參考來訪問的時候，以至於high_water_mark能夠正確的更新。
