繼承是面向?qū)ο笾泻苤匾母拍睢Ｈ绻紤]到Java語(yǔ)言特性，繼承分為兩種：接口繼承和實(shí)現(xiàn)繼承。這只是技術(shù)層面的問(wèn)題，即便C++中不存在接口的概念，但它的虛基類(lèi)實(shí)際上也相當(dāng)于接口。對(duì)于OO的初學(xué)者來(lái)說(shuō)，他們很希望自己的程序中出現(xiàn)大量的繼承，因?yàn)檫@樣看起來(lái)很OO。但濫用繼承會(huì)帶來(lái)很多問(wèn)題，盡管有時(shí)候我們又不得不使用繼承解決問(wèn)題。

相比于接口繼承，實(shí)現(xiàn)繼承的問(wèn)題要更多，它會(huì)帶來(lái)更多的耦合問(wèn)題。但接口繼承也是有問(wèn)題的，這是繼承本身的問(wèn)題。實(shí)現(xiàn)繼承的很多問(wèn)題出于其自身實(shí)現(xiàn)上，這也是消除實(shí)現(xiàn)繼承的難點(diǎn)，因此這里重點(diǎn)討論實(shí)現(xiàn)繼承的問(wèn)題。

舉個(gè)例子(這個(gè)例子實(shí)在太老套了)。我要實(shí)現(xiàn)一個(gè)Stack類(lèi)，我想當(dāng)然地選擇Stack類(lèi)繼承于ArrayList類(lèi)(你也可以認(rèn)為我很想OO些或者出于本性的懶惰);現(xiàn)在又有了新的需求，需要實(shí)現(xiàn)一個(gè)線程安全的Stack，我又定義了一個(gè)ConcurrentStack類(lèi)繼承于Stack并覆蓋了Stack中的部分代碼。

因?yàn)镾tack繼承于ArrayList，Stack不得不對(duì)外暴露出ArrayList所有的public方法，即便其中的某些方法對(duì)它可能是不需要的;甚至更糟的是，可能其中的某些方法能改變Stack的狀態(tài)，而Stack對(duì)這些改變并不知情，這就會(huì)造成Stack的邏輯錯(cuò)誤。

如果我要在ArrayList中添加新的方法，這個(gè)方法就有可能在邏輯上破壞它的派生類(lèi)Stack、 ConcurrentStack。因此在基類(lèi)(父類(lèi))添加方法(修改代碼)時(shí)，必須檢查這些修改是否會(huì)對(duì)派生類(lèi)產(chǎn)生影響;如果產(chǎn)生影響的話，就不得不對(duì)派生類(lèi)做進(jìn)一步的修改。如果類(lèi)的繼承體系不是一個(gè)人完成的，或者是修改別人的代碼的情況下，很可能因?yàn)槔^承產(chǎn)生難以覺(jué)察的BUG。

問(wèn)題還是有的。我們有時(shí)會(huì)見(jiàn)到這樣的基類(lèi)，它的一些方法只是拋出異常，這意味著如果派生類(lèi)支持這個(gè)方法就重寫(xiě)它，否則就如父類(lèi)一樣拋出異常表明其不支持這個(gè)方法的調(diào)用。我們也能見(jiàn)到它的一個(gè)變種，父類(lèi)的方法是抽象的，但不是所有的子類(lèi)都支持這個(gè)方法，不支持的方法就以拋出異常的方式表明立場(chǎng)。這種做法是很不友好和很不安全的，它們只能在運(yùn)行時(shí)被“僥幸捕捉”，而很多漏網(wǎng)的異常方法可能會(huì)在某一天突然出現(xiàn)，讓人不知所措。

引起上面問(wèn)題的很重要的原因便是基類(lèi)和派生類(lèi)之間的耦合。往往只是對(duì)基類(lèi)做了小小的改動(dòng)，卻不得不重構(gòu)它們的所有的派生類(lèi)，這就是臭名昭著的“脆弱的基類(lèi)”問(wèn)題。由于類(lèi)之間的關(guān)系是存在的，因此耦合是不可避免的甚至是必要的。但在做OO設(shè)計(jì)時(shí)，當(dāng)遇到如基類(lèi)和派生類(lèi)之間的強(qiáng)耦合關(guān)系，我們就要思量思量，是否一定需要繼承呢?是否會(huì)有其他的更優(yōu)雅的替代方案呢?如果一定要學(xué)究的話，你會(huì)在很多書(shū)中會(huì)看到這樣的原則：如果兩個(gè)類(lèi)之間是IS-A關(guān)系，那么就使用繼承;如果兩個(gè)類(lèi)之間是Has-A的關(guān)系，那么就使用委派。很多時(shí)候這條原則是適用的，但I(xiàn)S-A并不能做為使用繼承的絕對(duì)理由。有時(shí)為了消除耦合帶來(lái)的問(wèn)題，使用委派等方法會(huì)更好地封裝實(shí)現(xiàn)細(xì)節(jié)。繼承有時(shí)會(huì)對(duì)外及向下暴露太多的信息，在GOF的設(shè)計(jì)模式中，有很多模式的目的就是為了消除繼承。

關(guān)于何時(shí)采用繼承，一個(gè)重要的原則是確定方法是否能夠共享。比如DAO ，可以將通用的CRUD 方法定在一個(gè)抽象DAO 中，具體的DAO 都派生自這個(gè)抽象類(lèi)。嚴(yán)格的說(shuō)，抽象DAO 和派生的DAO 實(shí)現(xiàn)并不具有IS -A 關(guān)系，我們只是為了避免重復(fù)的方法定義和實(shí)現(xiàn)而作出了這一技術(shù)上的選擇。可以說(shuō)，使用接口還是抽象類(lèi)的原則是，如果多個(gè)派生類(lèi)的方法內(nèi)容沒(méi)有共同的地方，就用接口作為抽象;如果 多個(gè)派生類(lèi) 的方法含有共同的地方，就用抽象類(lèi)作為抽象。當(dāng)這一原則不適用于接口繼承，如果出現(xiàn)接口繼承，就會(huì)相應(yīng)地有實(shí)現(xiàn)繼承(基類(lèi)更多的是抽象類(lèi))。

現(xiàn)在說(shuō)說(shuō)面向接口編程。在眾多的敏捷方法中，面向接口編程總是被大師們反復(fù)的強(qiáng)調(diào)。面向接口編程，實(shí)際上是面向抽象編程，將抽象概念和具體實(shí)現(xiàn)相隔離。這一原則使得我們擁有了更高層次的抽象模型，在面對(duì)不斷變更的需求時(shí)，只要抽象模型做的好，修改代碼就要容易的多。但面向接口編程不意味著非得一個(gè)接口對(duì)應(yīng)一個(gè)類(lèi)，過(guò)多的不必要的接口也可能帶來(lái)更多的工作量和維護(hù)上的困難。

相比于繼承，OO中多態(tài)的概念要更重要。一個(gè)接口可以對(duì)應(yīng)多個(gè)實(shí)現(xiàn)類(lèi)，對(duì)于聲明為接口類(lèi)型的方法參數(shù)、類(lèi)的字段，它們要比實(shí)現(xiàn)類(lèi)更易于擴(kuò)展、穩(wěn)定，這也是多態(tài)的優(yōu)點(diǎn)。假如我以實(shí)現(xiàn)類(lèi)作為方法參數(shù)定義了一個(gè)方法void doSomething(ArrayList list)，但如果領(lǐng)導(dǎo)哪天覺(jué)得 ArrayList不如LinkedList更好用，我將不得不將方法重構(gòu)為void doSomething(LinkedList list)，相應(yīng)地要在所有調(diào)用此方法的地方修改參數(shù)類(lèi)型(很遺憾地，我連對(duì)象創(chuàng)建也是采用ArrayList list = new ArrayList()方式，這將大大增加我的修改工作量)。如果領(lǐng)導(dǎo)又覺(jué)得用list存儲(chǔ)數(shù)據(jù)不如set好的話，我將再一次重構(gòu)方法，但這一次我變聰明了，我將方法定義為void doSomething(Set set)，創(chuàng)建對(duì)象的方式改為Set set = new HashSet()。但這樣仍不夠，如果領(lǐng)導(dǎo)又要求將set改回list怎么辦?所以我應(yīng)該將方法重構(gòu)為void doSomething(Collection collection)， Collection的抽象程度***，更易于替換具體的實(shí)現(xiàn)類(lèi)。即便需要List或者Set固有的特性，我也可以做向下類(lèi)型轉(zhuǎn)換解決問(wèn)題，盡管這樣做并不安全。

面向接口編程最重要的價(jià)值在于隱藏實(shí)現(xiàn)，將抽象的實(shí)現(xiàn)細(xì)節(jié)封裝起來(lái)而不對(duì)外開(kāi)放，封裝這對(duì)于Java EE 中的分層設(shè)計(jì)和框架設(shè)計(jì)尤其重要。但即便在編程時(shí)使用了接口，我們也需要將接口和實(shí)現(xiàn)對(duì)應(yīng)起來(lái)，這就引出如何創(chuàng)建對(duì)象的問(wèn)題。在創(chuàng)建型設(shè)計(jì)模式中，單例、工廠方法(模板方法)、抽象工廠等模式都是很好的解決辦法。現(xiàn)在流行的控制反轉(zhuǎn)(也叫依賴(lài)注入)模式是以聲明的方式將抽象與實(shí)現(xiàn)連接起來(lái)，這既減少了單調(diào)的工廠類(lèi)也更易于單元測(cè)試。

做個(gè)總結(jié)吧。盡管我竭力批駁繼承的不好鼓吹接口的好，但這并不是絕對(duì)的。濫用繼承、濫用接口都會(huì)帶來(lái)問(wèn)題。做Java EE開(kāi)發(fā)的很多朋友抱怨DAO、Service中一個(gè)接口一個(gè)類(lèi)的實(shí)現(xiàn)方式，盡管它們似乎看起來(lái)已成為業(yè)界的***實(shí)踐之一。也許排除掉面向接口編程更“瘦”一些，但“瘦”并一定就“好”，需要根據(jù)項(xiàng)目的具體情況而定。關(guān)于繼承和接口的***實(shí)踐，各位看官還是需要自身的經(jīng)驗(yàn)積累和總結(jié)了。