大多數(shù)好的設(shè)計(jì)者象躲避瘟疫一樣來(lái)避免使用實(shí)現(xiàn)繼承(extends 關(guān)系)。實(shí)際上80%的代碼應(yīng)該完全用interfaces寫，而不是通過(guò)extends。“Java設(shè)計(jì)模式”一書詳細(xì)闡述了怎樣用接口繼承代替實(shí)現(xiàn)繼承。這篇文章描述設(shè)計(jì)者為什么會(huì)這么作。

　　Extends是有害的；也許對(duì)于Charles Manson這個(gè)級(jí)別的不是，但是足夠糟糕的它應(yīng)該在任何可能的時(shí)候被避開(kāi)。“JAVA設(shè)計(jì)模式”一書花了很大的部分討論用interface繼承代替實(shí)現(xiàn)繼承。

　　好的設(shè)計(jì)者在他的代碼中，大部分用interface，而不是具體的基類。本文討論為什么設(shè)計(jì)者會(huì)這樣選擇，并且也介紹一些基于interface的編程基礎(chǔ)。

　　接口（Interface）和類（Class）?

　　一次，我參加一個(gè)Java用戶組的會(huì)議。在會(huì)議中，Jams Gosling（Java之父）做發(fā)起人講話。在那令人難忘的QA部分中，有人問(wèn)他：“如果你重新構(gòu)造Java，你想改變什么？”。“我想拋棄classes”他回答。在笑聲平息后，它解釋說(shuō)，真正的問(wèn)題不是由于class本身，而是實(shí)現(xiàn)繼承(extends) 關(guān)系。接口繼承（implements關(guān)系）是更好的。你應(yīng)該盡可能的避免實(shí)現(xiàn)繼承。

　　失去了靈活性

　　為什么你應(yīng)該避免實(shí)現(xiàn)繼承呢？第一個(gè)問(wèn)題是明確的使用具體類名將你固定到特定的實(shí)現(xiàn)，給底層的改變?cè)黾恿瞬槐匾睦щy。

　　在當(dāng)前的敏捷編程方法中，核心是并行的設(shè)計(jì)和開(kāi)發(fā)的概念。在你詳細(xì)設(shè)計(jì)程序前，你開(kāi)始編程。這個(gè)技術(shù)不同于傳統(tǒng)方法的形式----傳統(tǒng)的方式是設(shè)計(jì)應(yīng)該在編碼開(kāi)始前完成----但是許多成功的項(xiàng)目已經(jīng)證明你能夠更快速的開(kāi)發(fā)高質(zhì)量代碼，相對(duì)于傳統(tǒng)的按部就班的方法。但是在并行開(kāi)發(fā)的核心是主張靈活性。你不得不以某一種方式寫你的代碼以至于最新發(fā)現(xiàn)的需求能夠盡可能沒(méi)有痛苦的合并到已有的代碼中。

　　勝于實(shí)現(xiàn)你也許需要的特征，你只需實(shí)現(xiàn)你明確需要的特征，而且適度的對(duì)變化的包容。如果你沒(méi)有這種靈活，并行的開(kāi)發(fā)，那簡(jiǎn)直不可能。

　　對(duì)于Inteface的編程是靈活結(jié)構(gòu)的核心。為了說(shuō)明為什么，讓我們看一下當(dāng)使用它們的時(shí)候，會(huì)發(fā)生什么。考慮下面的代碼：

　　f()
　　{
　　LinkedList list = new LinkedList();
　　//...
　　g( list );
　　}

　　g( LinkedList list )
　　{
　　list.add( ... );
　　g2( list )
　　}

　　假設(shè)一個(gè)對(duì)于快速查詢的需求被提出，以至于這個(gè)LinkedList不能夠解決。你需要用HashSet來(lái)代替它。在已有代碼中，變化不能夠局部化，因?yàn)槟悴粌H僅需要修改f()也需要修改g()（它帶有LinkedList參數(shù)），并且還有g(shù)()把列表傳遞給的任何代碼。象下面這樣重寫代碼:

　　f()
　　{
　　Collection list = new LinkedList();
　　//...
　　g( list );
　　}

　　g( Collection list )
　　{
　　list.add( ... );
　　g2( list )
　　}

　　這樣修改Linked list成hash，可能只是簡(jiǎn)單的用new HashSet()代替new LinkedList()。就這樣。沒(méi)有其他的需要修改的地方。

　　作為另一個(gè)例子，比較下面兩段代碼：

　　f()
　　{
　　Collection c = new HashSet();
　　//...
　　g( c );
　　}

　　g( Collection c )
　　{
　　for( Iterator i = c.iterator(); i.hasNext() )
　　do_something_with( i.next() );
　　}

　　和

　　f2()
　　{
　　Collection c = new HashSet();
　　//...
　　g2( c.iterator() );
　　}

　　g2( Iterator i )
　　{
　　while( i.hasNext() )
　　do_something_with( i.next() );
　　}


　　g2()方法現(xiàn)在能夠遍歷Collection的派生，就像你能夠從Map中得到的鍵值對(duì)。事實(shí)上，你能夠?qū)慽terator，它產(chǎn)生數(shù)據(jù)，代替遍歷一個(gè)Collection。你能夠?qū)慽terator，它從測(cè)試的框架或者文件中得到信息。這會(huì)有巨大的靈活性。

　　耦合

　　對(duì)于實(shí)現(xiàn)繼承，一個(gè)更加關(guān)鍵的問(wèn)題是耦合---令人煩躁的依賴，就是那種程序的一部分對(duì)于另一部分的依賴。全局變量提供經(jīng)典的例子，證明為什么強(qiáng)耦合會(huì)引起麻煩。例如，如果你改變?nèi)肿兞康念愋停敲此杏玫竭@個(gè)變量的函數(shù)也許都被影響，所以所有這些代碼都要被檢查，變更和重新測(cè)試。而且，所有用到這個(gè)變量的函數(shù)通過(guò)這個(gè)變量相互耦合。也就是，如果一個(gè)變量值在難以使用的時(shí)候被改變，一個(gè)函數(shù)也許就不正確的影響了另一個(gè)函數(shù)的行為。這個(gè)問(wèn)題顯著的隱藏于多線程的程序。

　　作為一個(gè)設(shè)計(jì)者，你應(yīng)該努力最小化耦合關(guān)系。你不能一并消除耦合，因?yàn)閺囊粋€(gè)類的對(duì)象到另一個(gè)類的對(duì)象的方法調(diào)用是一個(gè)松耦合的形式。你不可能有一個(gè)程序，它沒(méi)有任何的耦合。然而，你能夠通過(guò)遵守OO規(guī)則，最小化一定的耦合（最重要的是，一個(gè)對(duì)象的實(shí)現(xiàn)應(yīng)該完全隱藏于使用他的對(duì)象）。例如，一個(gè)對(duì)象的實(shí)例變量（不是常量的成員域），應(yīng)該總是private。我意思是某段時(shí)期的，無(wú)例外的，不斷的。（你能夠偶爾有效地使用protected方法，但是protected實(shí)例變量是可憎的事）同樣的原因你應(yīng)該不用get/set函數(shù)---他們對(duì)于是一個(gè)域公用只是使人感到過(guò)于復(fù)雜的方式（盡管返回修飾的對(duì)象而不是基本類型值的訪問(wèn)函數(shù)是在某些情況下是由原因的，那種情況下，返回的對(duì)象類是一個(gè)在設(shè)計(jì)時(shí)的關(guān)鍵抽象）。

　　這里，我不是書生氣。在我自己的工作中，我發(fā)現(xiàn)一個(gè)直接的相互關(guān)系在我OO方法的嚴(yán)格之間，快速代碼開(kāi)發(fā)和容易的代碼實(shí)現(xiàn)。無(wú)論什么時(shí)候我違反中心的OO原則，如實(shí)現(xiàn)隱藏，我結(jié)果重寫那個(gè)代碼（一般因?yàn)榇a是不可調(diào)試的）。我沒(méi)有時(shí)間重寫代碼，所以我遵循那些規(guī)則。我關(guān)心的完全實(shí)用?我對(duì)干凈的原因沒(méi)有興趣。

　　 脆弱的基類問(wèn)題

　　現(xiàn)在，讓我們應(yīng)用耦合的概念到繼承。在一個(gè)用extends的繼承實(shí)現(xiàn)系統(tǒng)中，派生類是非常緊密的和基類耦合，當(dāng)且這種緊密的連接是不期望的。設(shè)計(jì)者已經(jīng)應(yīng)用了綽號(hào)“脆弱的基類問(wèn)題”去描述這個(gè)行為。基礎(chǔ)類被認(rèn)為是脆弱的是，因?yàn)槟阍诳雌饋?lái)安全的情況下修改基類，但是當(dāng)從派生類繼承時(shí)，新的行為也許引起派生類出現(xiàn)功能紊亂。你不能通過(guò)簡(jiǎn)單的在隔離下檢查基類的方法來(lái)分辨基類的變化是安全的；而是你也必須看（和測(cè)試）所有派生類。而且，你必須檢查所有的代碼，它們也用在基類和派生類對(duì)象中，因?yàn)檫@個(gè)代碼也許被新的行為所打破。一個(gè)對(duì)于基礎(chǔ)類的簡(jiǎn)單變化可能導(dǎo)致整個(gè)程序不可操作。

　　讓我們一起檢查脆弱的基類和基類耦合的問(wèn)題。下面的類extends了Java的ArrayList類去使它像一個(gè)stack來(lái)運(yùn)轉(zhuǎn)：

　　class Stack extends ArrayList
　　{
　　private int stack_pointer = 0;

　　public void push( Object article )
　　{
　　add( stack_pointer++, article );
　　}

　　public Object pop()
　　{
　　return remove( --stack_pointer );
　　}

　　public void push_many( Object[] articles )
　　{
　　for( int i = 0; i articles.length; ++i )
　　　push( articles[i] );
　　}
　　}

　　甚至一個(gè)象這樣簡(jiǎn)單的類也有問(wèn)題。思考當(dāng)一個(gè)用戶平衡繼承和用ArrayList的clear()方法去彈出堆棧時(shí)：

　　Stack a_stack = new Stack();
　　a_stack.push("1");
　　a_stack.push("2");
　　a_stack.clear();

　　這個(gè)代碼成功編譯，但是因?yàn)榛惒恢狸P(guān)于stack指針堆棧的情況,這個(gè)stack對(duì)象當(dāng)前在一個(gè)未定義的狀態(tài)。下一個(gè)對(duì)于push（）調(diào)用把新的項(xiàng)放入索引2的位置。（stack_pointer的當(dāng)前值），所以stack有效地有三個(gè)元素-下邊兩個(gè)是垃圾。（Java的stack類正是有這個(gè)問(wèn)題，不要用它）.

　　對(duì)這個(gè)令人討厭的繼承的方法問(wèn)題的解決辦法是為Stack覆蓋所有的ArrayList方法，那能夠修改數(shù)組的狀態(tài)，所以覆蓋正確的操作Stack指針或者拋出一個(gè)例外。(removeRange()方法對(duì)于拋出一個(gè)例外一個(gè)好的候選方法)。

　　這個(gè)方法有兩個(gè)缺點(diǎn)。第一，如果你覆蓋了所有的東西，這個(gè)基類應(yīng)該真正的是一個(gè)interface，而不是一個(gè)class。如果你不用任何繼承方法，在實(shí)現(xiàn)繼承中就沒(méi)有這一點(diǎn)。第二，更重要的是，你不能夠讓一個(gè)stack支持所有的ArrayList方法。例如，令人煩惱的removeRange()沒(méi)有什么作用。唯一實(shí)現(xiàn)無(wú)用方法的合理的途徑是使它拋出一個(gè)例外，因?yàn)樗鼞?yīng)該永遠(yuǎn)不被調(diào)用。這個(gè)方法有效的把編譯錯(cuò)誤成為運(yùn)行錯(cuò)誤。不好的方法是，如果方法只是不被定義，編譯器會(huì)輸出一個(gè)方法未找到的錯(cuò)誤。如果方法存在，但是拋出一個(gè)例外，你只有在程序真正的運(yùn)行時(shí)，你才能夠發(fā)現(xiàn)調(diào)用錯(cuò)誤。

　　對(duì)于這個(gè)基類問(wèn)題的一個(gè)更好的解決辦法是封裝數(shù)據(jù)結(jié)構(gòu)代替用繼承。這是新的和改進(jìn)的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] );
　　}
　　}

　　到現(xiàn)在為止，一直都不錯(cuò)，但是考慮脆弱的基類問(wèn)題，我們說(shuō)你想要在stack創(chuàng)建一個(gè)變量， 用它在一段周期內(nèi)跟蹤最大的堆棧尺寸。一個(gè)可能的實(shí)現(xiàn)也許象下面這樣:

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

　　這個(gè)新類運(yùn)行的很好，至少是一段時(shí)間。不幸的是，這個(gè)代碼發(fā)掘了一個(gè)事實(shí)，push_many()通過(guò)調(diào)用push()來(lái)運(yùn)行。首先，這個(gè)細(xì)節(jié)看起來(lái)不是一個(gè)壞的選擇。它簡(jiǎn)化了代碼，并且你能夠得到push()的派生類版本，甚至當(dāng)Monitorable_stack通過(guò)Stack的參考來(lái)訪問(wèn)的時(shí)候，以至于high_water_mark能夠正確的更新。