在匆忙之際理清消除實現繼續和面向接口編程這樣兩個大題目可不是一件輕易的事情，尤其考慮到自身的熟悉水平。坦白的說，這又是一篇“炒冷飯”的文章，但這“冷飯”又確實不好炒。因此，在閱讀了這篇文章之后，你可要批判地接受(拒盡)我的觀點，盡管我的觀點也是來自于別人的觀點。

繼續是面向對象中很重要的概念。假如考慮到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中一個接口一個類的實現方式，盡管它們似乎看起來已成為業界的最佳實踐之一。也許排除掉接口會使程序更“瘦”一些，但“瘦”并一定就“好”，需要根據項目的具體情況而定。關于繼續和接口的最佳實踐，各位看官還是需要自身的經驗積累和總結了。

總結

以上是生活随笔為你收集整理的java继续_Java中消除实现继续和面向接口编程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。