為什么說Java中繼承是有害的

實際上80%的代碼應(yīng)該完全用interfaces寫，而不是通過extends。“JAVA設(shè)計模式”一書詳細闡述了怎樣用接口繼承代替實現(xiàn)繼承。這篇文章描述設(shè)計者為什么會這么作。 Extends是有害的；也許對于Charles Manson這個級別的不是，但是足夠糟糕的它應(yīng)該在任何可能的時候被避開。“JAVA設(shè)計模式”一書花了很大的部分討論用interface繼承代替實現(xiàn)繼承。 好的設(shè)計者在他的代碼中，大部分用interface，而不是具體的基類。本文討論為什么設(shè)計者會這樣選擇，并且也介紹一些基于interface的編程基礎(chǔ)。 接口（Interface）和類（Class）? 一次，我參加一個Java用戶組的會議。在會議中，Jams Gosling（Java之父）做發(fā)起人講話。在那令人難忘的QA部唯或分，有人問他：“如果你重新構(gòu)造Java，你想改變什么？”。“我想拋棄classes”他回答。在笑聲平息后，它解釋說，真正的問題不是由于class本身，而是實現(xiàn)繼承(extends 關(guān)系)。接口繼承（implements關(guān)系）是更好的。你應(yīng)該盡可能的避免實現(xiàn)繼承。 失卜腔去了靈活性 為什么你應(yīng)該避免實現(xiàn)繼承呢？第一個問題是明確的使用具體類名將你固定到特定的實現(xiàn)，給底層的改變增加了不必要的困難。 在當前的敏捷編程方法中，型山衫核心是并行的設(shè)計和開發(fā)的概念。在你詳細設(shè)計程序前，你開始編程。這個技術(shù)不同于傳統(tǒng)方法的形式----傳統(tǒng)的方式是設(shè)計應(yīng)該在編碼開始前完成----但是許多成功的項目已經(jīng)證明你能夠更快速的開發(fā)高質(zhì)量代碼，相對于傳統(tǒng)的按部就班的方法。但是在并行開發(fā)的核心是主張靈活性。你不得不以某一種方式寫你的代碼以至于最新發(fā)現(xiàn)的需求能夠盡可能沒有痛苦的合并到已有的代碼中。 勝于實現(xiàn)你也許需要的特征，你只需實現(xiàn)你明確需要的特征，而且適度的對變化的包容。如果你沒有這種靈活，并行的開發(fā)，那簡直不可能。 對于Inteface的編程是靈活結(jié)構(gòu)的核心。為了說明為什么，讓我們看一下當使用它們的時候，會發(fā)生什么。考慮下面的代碼：f(){ LinkedList list = new LinkedList();//...g( list );}g( LinkedList list ){list.add( ... );g2( list )} 現(xiàn)在，假設(shè)一個對于快速查詢的需求被提出，以至于這個LinkedList不能夠解決。你需要用HashSet來代替它。在已有代碼中，變化不能夠局部化，因為你不僅僅需要修改f()也需要修改g()（它帶有LinkedList參數(shù)），并且還有g(shù)()把列表傳遞給的任何代碼。象下面這樣重寫代碼: 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()方法現(xiàn)在能夠遍歷Collection的派生，就像你能夠從Map中得到的鍵值對。事實上，你能夠?qū)慽terator，它產(chǎn)生數(shù)據(jù)，代替遍歷一個Collection。你能夠?qū)慽terator，它從測試的框架或者文件中得到信息。這會有巨大的靈活性。 耦合 對于實現(xiàn)繼承，一個更加關(guān)鍵的問題是耦合---令人煩躁的依賴，就是那種程序的一部分對于另一部分的依賴。全局變量提供經(jīng)典的例子，證明為什么強耦合會引起麻煩。例如，如果你改變?nèi)肿兞康念愋停敲此杏玫竭@個變量的函數(shù)也許都被影響，所以所有這些代碼都要被檢查，變更和重新測試。而且，所有用到這個變量的函數(shù)通過這個變量相互耦合。也就是，如果一個變量值在難以使用的時候被改變，一個函數(shù)也許就不正確的影響了另一個函數(shù)的行為。這個問題顯著的隱藏于多線程的程序。 作為一個設(shè)計者，你應(yīng)該努力最小化耦合關(guān)系。你不能一并消除耦合，因為從一個類的對象到另一個類的對象的方法調(diào)用是一個松耦合的形式。你不可能有一個程序，它沒有任何的耦合。然而，你能夠通過遵守OO規(guī)則，最小化一定的耦合（最重要的是，一個對象的實現(xiàn)應(yīng)該完全隱藏于使用他的對象）。例如，一個對象的實例變量（不是常量的成員域），應(yīng)該總是private。我意思是某段時期的，無例外的，不斷的。（你能夠偶爾有效地使用protected方法，但是protected實例變量是可憎的事）同樣的原因你應(yīng)該不用get/set函數(shù)---他們對于是一個域公用只是使人感到過于復(fù)雜的方式（盡管返回修飾的對象而不是基本類型值的訪問函數(shù)是在某些情況下是由原因的，那種情況下，返回的對象類是一個在設(shè)計時的關(guān)鍵抽象）。 這里，我不是書生氣。在我自己的工作中，我發(fā)現(xiàn)一個直接的相互關(guān)系在我OO方法的嚴格之間，快速代碼開發(fā)和容易的代碼實現(xiàn)。無論什么時候我違反中心的OO原則，如實現(xiàn)隱藏，我結(jié)果重寫那個代碼（一般因為代碼是不可調(diào)試的）。我沒有時間重寫代碼，所以我遵循那些規(guī)則。我關(guān)心的完全實用?我對干凈的原因沒有興趣。 脆弱的基類問題 現(xiàn)在，讓我們應(yīng)用耦合的概念到繼承。在一個用extends的繼承實現(xiàn)系統(tǒng)中，派生類是非常緊密的和基類耦合，當且這種緊密的連接是不期望的。設(shè)計者已經(jīng)應(yīng)用了綽號“脆弱的基類問題”去描述這個行為。基礎(chǔ)類被認為是脆弱的是，因為你在看起來安全的情況下修改基類，但是當從派生類繼承時，新的行為也許引起派生類出現(xiàn)功能紊亂。你不能通過簡單的在隔離下檢查基類的方法來分辨基類的變化是安全的；而是你也必須看（和測試）所有派生類。而且，你必須檢查所有的代碼，它們也用在基類和派生類對象中，因為這個代碼也許被新的行為所打破。一個對于基礎(chǔ)類的簡單變化可能導(dǎo)致整個程序不可操作。讓我們一起檢查脆弱的基類和基類耦合的問題。下面的類extends了Java的ArrayList類去使它像一個stack來運轉(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] );}}甚至一個象這樣簡單的類也有問題。思考當一個用戶平衡繼承和用ArrayList的clear()方法去彈出堆棧時： Stack a_stack = new Stack(); a_stack.push("1");a_stack.push("2");a_stack.clear();這個代碼成功編譯，但是因為基類不知道關(guān)于stack指針堆棧的情況,這個stack對象當前在一個未定義的狀態(tài)。下一個對于push（）調(diào)用把新的項放入索引2的位置。（stack_pointer的當前值），所以stack有效地有三個元素-下邊兩個是垃圾。（Java的stack類正是有這個問題，不要用它）. 對這個令人討厭的繼承的方法問題的解決辦法是為Stack覆蓋所有的ArrayList方法，那能夠修改數(shù)組的狀態(tài)，所以覆蓋正確的操作Stack指針或者拋出一個例外。(removeRange()方法對于拋出一個例外一個好的候選方法)。 這個方法有兩個缺點。第一，如果你覆蓋了所有的東西，這個基類應(yīng)該真正的是一個interface，而不是一個class。如果你不用任何繼承方法，在實現(xiàn)繼承中就沒有這一點。第二，更重要的是，你不能夠讓一個stack支持所有的ArrayList方法。例如，令人煩惱的removeRange()沒有什么作用。唯一實現(xiàn)無用方法的合理的途徑是使它拋出一個例外，因為它應(yīng)該永遠不被調(diào)用。這個方法有效的把編譯錯誤成為運行錯誤。不好的方法是，如果方法只是不被定義，編譯器會輸出一個方法未找到的錯誤。

做網(wǎng)站、成都網(wǎng)站建設(shè)的開發(fā)，更需要了解用戶，從用戶角度來建設(shè)網(wǎng)站，獲得較好的用戶體驗。創(chuàng)新互聯(lián)多年互聯(lián)網(wǎng)經(jīng)驗，見的多，溝通容易、能幫助客戶提出的運營建議。作為成都一家網(wǎng)絡(luò)公司，打造的就是網(wǎng)站建設(shè)產(chǎn)品直銷的概念。選擇創(chuàng)新互聯(lián)，不只是建站，我們把建站作為產(chǎn)品，不斷的更新、完善，讓每位來訪用戶感受到浩方產(chǎn)品的價值服務(wù)。

網(wǎng)頁標題：java代碼的繼承 java 繼承
網(wǎng)站鏈接：http://chinadenli.net/article17/dspjogj.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計、面包屑導(dǎo)航、企業(yè)網(wǎng)站制作、網(wǎng)站設(shè)計公司、動態(tài)網(wǎng)站、手機網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)