為什么更推薦使用組合而非繼承關系?-創(chuàng)新互聯(lián)

前言

最近在看公司項目的代碼,看到了大量的繼承體系,而且還是繼承了多層,維護、閱讀都十分的困難。在查閱了一些資料以后,包括《Effective Java》一書中的第16條提到“組合優(yōu)先于繼承”。那繼承到底會暴露什么問題呢?為什么更推薦優(yōu)先使用組合呢?

創(chuàng)新互聯(lián)服務項目包括天全網站建設、天全網站制作、天全網頁制作以及天全網絡營銷策劃等。多年來,我們專注于互聯(lián)網行業(yè),利用自身積累的技術優(yōu)勢、行業(yè)經驗、深度合作伙伴關系等,向廣大中小型企業(yè)、政府機構等提供互聯(lián)網行業(yè)的解決方案,天全網站推廣取得了明顯的社會效益與經濟效益。目前,我們服務的客戶以成都為中心已經輻射到天全省份的部分城市,未來相信會繼續(xù)擴大服務區(qū)域并繼續(xù)獲得客戶的支持與信任!

歡迎關注微信公眾號「JAVA旭陽」交流和學習

繼承帶來的問題

老實講,項目中為什么大量使用繼承,估計初版設計的人是想實現(xiàn)代碼的復用,但是的確帶來不少的問題。

繼承是面向對象重要特性之一,語義上是表達is-a的關系,但是它會破壞封裝性。我們舉個例子:

假設我們要設計一個關于鳥的類。我們將“鳥類”這樣一個抽象的事物概念,定義為一個抽象類AbstractBird,默認有eat吃東西的行為。所有更細分的鳥,比如麻雀、鴿子、鴕鳥等,都繼承這個抽象類。

public class AbstractBird { 
 	//... 省略其他屬性和方法... 
 	public void eat() { //... }
}

// 鴕鳥
public class Ostrich extends AbstractBird { 

}

但是,這時候搞不清楚情況的人根據需求給AbstractBird添加一個fly()的行為。但是對于鴕鳥這個子類來說,并不會飛,你如果不做任何處理,相當于讓鴕鳥有了飛翔的功能,不符合設計。聰明的你想到了,那就重寫以下吧,拋出一個異常,如下所示:

public class AbstractBird { 
 	//... 省略其他屬性和方法... 
 	public void eat() { //... }

    public void fly() { //... }
}

// 鴕鳥
public class Ostrich extends AbstractBird { 
 //... 省略其他屬性和方法... 
 public void fly() { 
     throw new UnSupportedMethodException("I can't fly.'");  
 }  
}

這種設計思路雖然可以解決問題,但不夠優(yōu)美。因為除了鴕鳥之外,不會飛的鳥還有很多,比如企鵝。對于這些不會飛的鳥來說,我們都需要重寫fly()方法,拋出異常。而且真正好的設計,對于鴕鳥和企鵝來說,就不應該暴露給他們fly()這種不該暴露的接口,增加外部調用的負擔。

這里只提到了fly(),如果還有下蛋egg()、唱歌sing()這么多行為,總不能都冗雜在父類里吧。關鍵像我們的項目同事,基本上把所有的類都寫到了父類中,真的特別難以維護。

小結一下繼承帶來的問題:

  1. 子類繼承了父類所有的行為,會讓子類無意的暴露的不必要的接口,破壞封裝性。
  2. 如果繼承層級比較多,那么代碼的復雜度、可閱讀型就可想而知的難了。
  3. 另外一個點,就是非常不好做單元測試。

針對于這種問題,組合能怎么解決呢?

組合的好處

組合,顧名思意,就是把另外一個對象做成當前這個對象的一部分,是組成我的一部分,它也能很好的實現(xiàn)代碼的復用,語義上表達的是has-a的意思,我有xxx的能力,我有xxx的功能。

那我們看看針對上面的例子,用組合的方式該如何實現(xiàn)呢?

  • 定義接口
public interface Eatable {
    void eat();
} 
public interface Flyable { 
    void fly(); 
} 

public class EatAbility implements Eatable { 
    @Override 
    public void eat() {
        System.out.println("I can eat");
    } 
}  // 省

public class FlyAbility implements Flyable { 
    @Override 
    public void fly() {
        System.out.println("I can fly");
    } 
}  // 省
  1. 組合鴕鳥類
public class Ostrich implements Eatable {// 鴕鳥
 	private Eatable eatable = new EatAbility(); // 組合
 	//... 省略其他屬性和方法... 
	@Override 
    public void eat() { 
        eatable.eat(); // 委托
	} 
}

你看對于鴕鳥這個子類來說,只暴露了它有的能力,那就是eat,沒有暴露fly的接口。

從理論上講,通過組合、接口、委托三個技術手段,我們完全可以替換掉繼承,在項目中不用或者少用繼承關系,特別是一些復雜的繼承關系。

繼承真的無用武之地了?

既然面向對象中有繼承這玩意,說明它并非一無是處的。

如果類之間的繼承結構穩(wěn)定(不會輕易改變),繼承層次比較淺(比如,最多有兩層繼承關系),繼承關系不復雜,我們就可以大膽地使用繼承。反之,系統(tǒng)越不穩(wěn)定,繼承層次很深,繼承關系復雜,我們就盡量使用組合來替代繼承。

除此之外,還有一些設計模式會固定使用繼承或者組合。比如,裝飾者模式(decorator pattern)、策略模式(strategy pattern)、組合模式(composite pattern)等都使用了組合關系,而模板模式(template pattern)使用了繼承關系。

總結

不知道大家項目中繼承用的多嗎?其實在JDK中就有許多違反這條原則的地方,比如棧Stack類并不是Vector,不應該有繼承關系,但是實際上就是繼承自Vector。不管如何,在項目中決定使用繼承而不是組合前,一定要考慮清楚,子類是否真的是父類的子類型?以后父類會不會經常變動的可能?父類的某些API是否存在缺陷,如果有的話也會隨著子類擴散出去。

歡迎關注微信公眾號「JAVA旭陽」交流和學習
更多學習資料請移步:程序員成神之路

你是否還在尋找穩(wěn)定的海外服務器提供商?創(chuàng)新互聯(lián)www.cdcxhl.cn海外機房具備T級流量清洗系統(tǒng)配攻擊溯源,準確流量調度確保服務器高可用性,企業(yè)級服務器適合批量采購,新人活動首月15元起,快前往官網查看詳情吧

本文標題:為什么更推薦使用組合而非繼承關系?-創(chuàng)新互聯(lián)
分享網址:http://www.bm7419.com/article22/cesgjc.html

成都網站建設公司_創(chuàng)新互聯(lián),為您提供移動網站建設網站排名、品牌網站設計企業(yè)建站、網站策劃網站收錄

廣告

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

外貿網站制作