建站
咨詢
售后
建站咨詢
新聞中心
?前言
最近在看公司項(xiàng)目的代碼，看到了大量的繼承體系，而且還是繼承了多層，維護(hù)、閱讀都十分的困難。在查閱了一些資料以后，包括《Effective Java》一書中的第16條提到“組合優(yōu)先于繼承”。那繼承到底會(huì)暴露什么問題呢？為什么更推薦優(yōu)先使用組合呢？
10年積累的成都網(wǎng)站制作、網(wǎng)站設(shè)計(jì)經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶對(duì)網(wǎng)站的新想法和需求。提供各種問題對(duì)應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先網(wǎng)站設(shè)計(jì)制作后付款的網(wǎng)站建設(shè)流程，更有平潭免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。
繼承帶來的問題
老實(shí)講，項(xiàng)目中為什么大量使用繼承，估計(jì)初版設(shè)計(jì)的人是想實(shí)現(xiàn)代碼的復(fù)用，但是的確帶來不少的問題。
繼承是面向?qū)ο笾匾匦灾?，語(yǔ)義上是表達(dá) is-a的關(guān)系，但是它會(huì)破壞封裝性。我們舉個(gè)例子：
假設(shè)我們要設(shè)計(jì)一個(gè)關(guān)于鳥的類。我們將“鳥類”這樣一個(gè)抽象的事物概念，定義為一個(gè)抽象類 AbstractBird?，默認(rèn)有eat吃東西的行為。所有更細(xì)分的鳥，比如麻雀、鴿子、鴕鳥等，都繼承這個(gè)抽象類。
public class AbstractBird {
//... 省略其他屬性和方法...
public void eat() { //... }
}
// 鴕鳥
public class Ostrich extends AbstractBird {
}但是，這時(shí)候搞不清楚情況的人根據(jù)需求給AbstractBird?添加一個(gè)fly()的行為。但是對(duì)于鴕鳥這個(gè)子類來說，并不會(huì)飛，你如果不做任何處理，相當(dāng)于讓鴕鳥有了飛翔的功能，不符合設(shè)計(jì)。聰明的你想到了，那就重寫以下吧，拋出一個(gè)異常，如下所示：
public class AbstractBird {
//... 省略其他屬性和方法...
public void eat() { //... }
public void fly() { //... }
}
// 鴕鳥
public class Ostrich extends AbstractBird {
//... 省略其他屬性和方法...
public void fly() {
throw new UnSupportedMethodException("I can't fly.'");
}
}這種設(shè)計(jì)思路雖然可以解決問題，但不夠優(yōu)美。因?yàn)槌锁r鳥之外，不會(huì)飛的鳥還有很多，比如企鵝。對(duì)于這些不會(huì)飛的鳥來說，我們都需要重寫 fly()?方法，拋出異常。而且真正好的設(shè)計(jì)，對(duì)于鴕鳥和企鵝來說，就不應(yīng)該暴露給他們fly()這種不該暴露的接口，增加外部調(diào)用的負(fù)擔(dān)。
這里只提到了fly()?,如果還有下蛋egg()?、唱歌sing()這么多行為，總不能都冗雜在父類里吧。關(guān)鍵像我們的項(xiàng)目同事，基本上把所有的類都寫到了父類中，真的特別難以維護(hù)。
小結(jié)一下繼承帶來的問題：
子類繼承了父類所有的行為，會(huì)讓子類無意的暴露的不必要的接口，破壞封裝性。
如果繼承層級(jí)比較多，那么代碼的復(fù)雜度、可閱讀型就可想而知的難了。
另外一個(gè)點(diǎn)，就是非常不好做單元測(cè)試。
針對(duì)于這種問題，組合能怎么解決呢？
組合的好處
組合，顧名思意，就是把另外一個(gè)對(duì)象做成當(dāng)前這個(gè)對(duì)象的一部分，是組成我的一部分，它也能很好的實(shí)現(xiàn)代碼的復(fù)用，語(yǔ)義上表達(dá)的是has-a的意思，我有xxx的能力，我有xxx的功能。
那我們看看針對(duì)上面的例子，用組合的方式該如何實(shí)現(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");
}
} // 省- 組合鴕鳥類
public class Ostrich implements Eatable {// 鴕鳥
private Eatable eatable = new EatAbility(); // 組合
//... 省略其他屬性和方法...
@Override
public void eat() {
eatable.eat(); // 委托
}
}你看對(duì)于鴕鳥這個(gè)子類來說，只暴露了它有的能力，那就是eat?，沒有暴露fly的接口。
從理論上講，通過組合、接口、委托三個(gè)技術(shù)手段，我們完全可以替換掉繼承，在項(xiàng)目中不用或者少用繼承關(guān)系，特別是一些復(fù)雜的繼承關(guān)系。
繼承真的無用武之地了？
既然面向?qū)ο笾杏欣^承這玩意，說明它并非一無是處的。
如果類之間的繼承結(jié)構(gòu)穩(wěn)定（不會(huì)輕易改變），繼承層次比較淺（比如，最多有兩層繼承關(guān)系），繼承關(guān)系不復(fù)雜，我們就可以大膽地使用繼承。反之，系統(tǒng)越不穩(wěn)定，繼承層次很深，繼承關(guān)系復(fù)雜，我們就盡量使用組合來替代繼承。
除此之外，還有一些設(shè)計(jì)模式會(huì)固定使用繼承或者組合。比如，裝飾者模式（decorator pattern?）、策略模式（strategy pattern?）、組合模式（composite pattern?）等都使用了組合關(guān)系，而模板模式（template pattern）使用了繼承關(guān)系。
總結(jié)
不知道大家項(xiàng)目中繼承用的多嗎？其實(shí)在JDK中就有許多違反這條原則的地方，比如棧Stack?類并不是Vector?，不應(yīng)該有繼承關(guān)系，但是實(shí)際上就是繼承自Vector。不管如何，在項(xiàng)目中決定使用繼承而不是組合前，一定要考慮清楚，子類是否真的是父類的子類型？以后父類會(huì)不會(huì)經(jīng)常變動(dòng)的可能？父類的某些API是否存在缺陷，如果有的話也會(huì)隨著子類擴(kuò)散出去。
新聞標(biāo)題：為什么更推薦使用組合而非繼承關(guān)系？
本文地址：http://www.dlmjj.cn/article/cdeghsi.html
