為什么extends是有害的（一）

2019-11-18 13:18:43

字體：大中小

來源：轉載

供稿：網友

　　概述
　　大多數好的設計者象躲避瘟疫一樣來避免使用實現繼續(extends 關系)。%80的代碼應該完全用interfaces寫，不用具體的基類。事實上，四人幫的設計模式的書大量的關于怎樣用interface繼續代替實現繼續。這個文章描述設計者為什么有這樣的怪癖的想法。
　　
　　Extends是有害的；也許對于Charles Manson這個級別的不是，但是足夠糟糕的它應該在任何的可能的時候被避開。四人幫的設計模式花了很大的部分討論用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原則，如實現隱藏，我結果重寫那個代碼（一般因為代碼是不可調試的）。我沒有時間重寫代碼，所以我遵循那些規則。我關心的完全實用—我對干凈的原因沒有愛好。
　　
　　脆弱的基類問題
　　現在，讓我們應用耦合的概念到繼續。在一個用extends的繼續實現系統中，派生類是非常緊密的和基類耦合，當且這種緊密的連接是不期望的。設計者已經應用了綽號“脆弱的基類問題”去描述這個行為。基礎類被認為是脆弱的是，因為你在看起來安全的情況下修改基類，但是當從派生類繼續時，新的行為也許引起派生類出現功能紊亂。你不能通過簡單的在隔離下檢查基類的方法來分辨基類的變化是安全的；而是你也必須看（和測試）所有派生類。而且，你必須檢查所有的代碼，它們也用在基類和派生類對象中，因為這個代碼也許被新的行為所打破。一個對于基礎類的簡單變化可能導致整個程序不可操作。
　　
　　讓我們一起檢查脆弱的基類和基類耦合的問題。下面的類extends了Java的ArrayList類去使它像一個stack來運轉：
　　[/代碼]
　　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] );
　　　　}
　　}
　　[/代碼]
　　
　　甚至一個象這樣簡單的類也有問題。思考當一個用戶平衡繼續和用ArrayList的clear()方法去彈出堆棧時：
　　[/代碼]
　　Stack a_stack = new Stack();
　　a_stack.push("1");
　　a_stack.push("2");
　　a_stack.clear();
　　[/代碼]
　　
　　這個代碼成功編譯，但是因為基類不知道關于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] );
　　}
　　}

上一篇：為什么extends是有害的（二）

下一篇：Java的內存泄漏