為什麼Java中繼承是有害的

為什麼Java中繼承是有害的[@more@]　　概述

　　大多數好的設計者象躲避瘟疫一樣來避免使用實現繼承(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()。就這樣。沒有其他的需要修改的地方。 作為另一個例子，比較下面兩段程式碼：

　　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()方法現在能夠遍歷Collection的派生，就像你能夠從Map中得到的鍵值對。事實上，你能夠寫iterator，它產生資料，代替遍歷一個Collection。你能夠寫iterator，它從測試的框架或者檔案中得到資訊。這會有巨大的靈活性。

　　耦合

　　對於實現繼承，一個更加關鍵的問題是耦合---令人煩躁的依賴，就是那種程式的一部分對於另一部分的依賴。全域性變數提供經典的例子，證明為什麼強耦合會引起麻煩。例如，如果你改變全域性變數的型別，那麼所有用到這個變數的函式也許都被影響，所以所有這些程式碼都要被檢查，變更和重新測試。而且，所有用到這個變數的函式透過這個變數相互耦合。也就是，如果一個變數值在難以使用的時候被改變，一個函式也許就不正確的影響了另一個函式的行為。這個問題顯著的隱藏於多執行緒的程式。

　　作為一個設計者，你應該努力最小化耦合關係。你不能一併消除耦合，因為從一個類的物件到另一個類的物件的方法呼叫是一個松耦合的形式。你不可能有一個程式，它沒有任何的耦合。然而，你能夠透過遵守OO規則，最小化一定的耦合（最重要的是，一個物件的實現應該完全隱藏於使用他的物件）。例如，一個物件的例項變數（不是常量的成員域），應該總是private。我意思是某段時期的，無例外的，不斷的。（你能夠偶爾有效地使用protected方法，但是protected例項變數是可憎的事）同樣的原因你應該不用get/set函式---他們對於是一個域公用只是使人感到過於複雜的方式（儘管返回修飾的物件而不是基本型別值的訪問函式是在某些情況下是由原因的，那種情況下，返回的物件類是一個在設計時的關鍵抽象）。

　　這裡，我不是書生氣。在我自己的工作中，我發現一個直接的相互關係在我OO方法的嚴格之間，快速程式碼開發和容易的程式碼實現。無論什麼時候我違反中心的OO原則，如實現隱藏，我結果重寫那個程式碼（一般因為程式碼是不可除錯的）。我沒有時間重寫程式碼，所以我遵循那些規則。我關心的完全實用—我對乾淨的原因沒有興趣。