在匆忙之際理清消除實現繼承和面向接口編程這樣兩個大問題可不是一件容易的事情，尤其考慮到自身的認識水平。坦白的說，這又是一篇“炒冷飯”的文章，但這“冷飯”又確實不好炒。因此，在閱讀了這篇文章之後，你可要批判地接受(拒絕)我的觀點，盡管我的觀點也是來自於別人的觀點。
繼承是面向對象中很重要的概念。如果考慮到Java語言特性，繼承分為兩種：接口繼承和實現繼承。這只是技術層面的問題，即便C++中不存在接口的概念，但它的虛基類實際上也相當於接口。對於OO的初學者來說，他們很希望自己的程序中出現大量的繼承，因為這樣看起來很OO。但濫用繼承會帶來很多問題，盡管有時候我們又不得不使用繼承解決問題。
相比於接口繼承，實現繼承的問題要更多，它會帶來更多的耦合問題。但接口繼承也是有問題的，這是繼承本身的問題。實現繼承的很多問題出於其自身實現上，因此這裡重點討論實現繼承的問題。
舉個例子(這個例子實在太老套了)。我要實現一個Stack類，我想當然地選擇Stack類繼承於ArrayList類(你也可以認為我很想OO些或者出於本性的懶惰);現在又有了新的需求，需要實現一個線程安全的Stack，我又定義了一個ConcurrentStack類繼承於Stack並覆蓋了Stack中的部分代碼。
因為Stack繼承於ArrayList，Stack不得不對外暴露出ArrayList所有的public方法，即便其中的某些方法對它可能是不需要的;甚至更糟的是，可能其中的某些方法能改變Stack的狀態，而Stack對這些改變並不知情，這就會造成Stack的邏輯錯誤。
如果我要在ArrayList中添加新的方法，這個方法就有可能在邏輯上破壞它的派生類Stack、 ConcurrentStack。因此在基類(父類)添加方法(修改代碼)時，必須檢查這些修改是否會對派生類產生影響;如果產生影響的話，就不得不對派生類做進一步的修改。如果類的繼承體系不是一個人完成的，或者是修改別人的代碼的情況下，很可能因為繼承產生難以覺察的BUG。
問題還是有的。我們有時會見到這樣的基類，它的一些方法只是拋出異常，這意味著如果派生類支持這個方法就重寫它，否則就如父類一樣拋出異常表明其不支持這個方法的調用。我們也能見到它的一個變種，父類的方法是抽象的，但不是所有的子類都支持這個方法，不支持的方法就以拋出異常的方式表明立場。這種做法是很不友好和很不安全的，它們只能在運行時被“僥幸捕捉”，而很多漏網的異常方法可能會在某一天突然出現，讓人不知所措。
引起上面問題的很重要的原因便是基類和派生類之間的耦合。往往只是對基類做了小小的改動，卻不得不重構它們的所有的派生類，這就是臭名昭著的“脆弱的基類”問題。由於類之間的關系是存在的，因此耦合是不可避免的甚至是必要的。但在做OO設計時，當遇到如基類和派生類之間的強耦合關系，我們就要思量思量，是否一定需要繼承呢？是否會有其他的更優雅的替代方案呢？如果一定要學究的話，你會在很多書中會看到這樣的原則：如果兩個類之間是IS-A關系，那麼就使用繼承;如果兩個類之間是Has-A的關系，那麼就使用委派。很多時候這條原則是適用的，但IS-A並不能做為使用繼承的絕對理由。有時為了消除耦合帶來的問題，使用委派等方法會更好地封裝實現細節。繼承有時會對外及向下暴露太多的信息，在GOF的設計模式中，有很多模式的目的就是為了消除繼承。
關於何時采用繼承，一個重要的原則是確定方法是否能夠共享。比如DAO ，可以將通用的CRUD 方法定在一個抽象DAO 中，具體的DAO 都派生自這個抽象類。嚴格的說，抽象DAO 和派生的DAO 實現並不具有IS -A 關系，我們只是為了避免重復的方法定義和實現而作出了這一技術上的選擇。可以說，使用接口還是抽象類的原則是，如果多個派生類的方法內容沒有共同的地方，就用接口作為抽象;如果 多個派生類 的方法含有共同的地方，就用抽象類作為抽象。當這一原則不適用於接口繼承，如果出現接口繼承，就會相應地有實現繼承(基類更多的是抽象類)。
現在說說面向接口編程。在眾多的敏捷方法中，面向接口編程總是被大師們反復的強調。面向接口編程，實際上是面向抽象編程，將抽象概念和具體實現相隔離。這一原則使得我們擁有了更高層次的抽象模型，在面對不斷變更的需求時，只要抽象模型做的好，修改代碼就要容易的多。但面向接口編程不意味著非得一個接口對應一個類，過多的不必要的接口也可能帶來更多的工作量和維護上的困難。
相比於繼承，OO中多態的概念要更重要。一個接口可以對應多個實現類，對於聲明為接口類型的方法參數、類的字段，它們要比實現類更易於擴展、穩定，這也是多態的優點。假如我以實現類作為方法參數定義了一個方法void doSomething(ArrayList list)，但如果領導哪天覺得 ArrayList不如LinkedList更好用，我將不得不將方法重構為void doSomething(LinkedList list)，相應地要在所有調用此方法的地方修改參數類型(很遺憾地，我連對象創建也是采用ArrayList list = new ArrayList()方式，這將大大增加我的修改工作量)。如果領導又覺得用list存儲數據不如set好的話，我將再一次重構方法，但這一次我變聰明了，我將方法定義為void doSomething(Set set)，創建對象的方式改為Set set = new HashSet()。但這樣仍不夠，如果領導又要求將set改回list怎麼辦？所以我應該將方法重構為void doSomething(Collection collection)， Collection的抽象程度最高，更易於替換具體的實現類。即便需要List或者Set固有的特性，我也可以做向下類型轉換解決問題，盡管這樣做並不安全。
面向接口編程最重要的價值在於隱藏實現，將抽象的實現細節封裝起來而不對外開放，封裝這對於Java EE 中的分層設計和框架設計尤其重要。但即便在編程時使用了接口，我們也需要將接口和實現對應起來，這就引出如何創建對象的問題。在創建型設計模式中，單例、工廠方法(模板方法)、抽象工廠等模式都是很好的解決辦法。現在流行的控制反轉(也叫依賴注入)模式是以聲明的方式將抽象與實現連接起來，這既減少了單調的工廠類也更易於單元測試。
做個總結吧。盡管我竭力批駁繼承的不好鼓吹接口的好，但這並不是絕對的。濫用繼承、濫用接口都會帶來問題。做Java EE開發的很多朋友抱怨DAO、Service中一個接口一個類的實現方式，盡管它們似乎看起來已成為業界的最佳實踐之一。也許排除掉接口會使程序更“瘦”一些，但“瘦”並一定就“好”，需要根據項目的具體情況而定。關於繼承和接口的最佳實踐，各位看官還是需要自身的經驗積累和總結了。
