java抽象類與接口的選擇
選擇Java接口還是抽象類
很多人有過這樣的疑問：為什麽有的地方必須使用接口而不是抽象類，而在另一些地方，又必須使用抽象類而不是接口呢？或者說，在考慮Java類的一般化問題時，很多人會在接口和抽象類之間猶豫不決，甚至隨便選擇一種。
實際上接口和抽象類的選擇不是隨心所欲的。要理解接口和抽象類的選擇原則，有兩個概念很重要：對象的行為和對象的實現。如果一個實體可以有多種實現方式，則在設計實體行為的描述方式時，應當達到這樣一個目標：在使用實體的時候，無需詳細了解實體行為的實現方式。也就是說，要把對象的行為和對象的實現分離開來。既然Java的接口和抽象類都可以定義不提供具體實現的方法，在分離對象的行為和對象的實現時，到底應該使用接口還是使用抽象類呢？
通過抽象類建立行為模型
在接口和抽象類的選擇上，必須遵守這樣一個原則：行為模型應該總是通過接口而不是抽象類定義。為了說明其原因，下面試著通過抽象類建立行為模型，看看會出現什麽問題。
假設要為銷售部門設計一個軟件，這個軟件包含一個“發動機”（Motor）實體。顯然無法在發動機對象中詳細地描述發動機的方方面面，只能描述某些對當前軟件來說重要的特征。至於發動機的哪些特征是重要的，則要與用戶（銷售部門）交流才能確定。
銷售部門的人要求每一個發動機都有一個稱為馬力的參數。對於他們來說，這是惟一值得關心的參數。基於這一判斷，可以把發動機的行為定義為以下行為。
行為1：查詢發動機的馬力，發動機將返回一個表示馬力的整數。
雖然現在還不清楚發動機如何取得馬力這個參數，但可以肯定發動機一定支持這個行為，而且這是所有發動機惟一值得關註的行為特征。這個行為特征既可以用接口定義，也可以用抽象類定義。為了說明用抽象類定義可能出現的問題，下面用抽象類建立發動機的行為模型，並用Java方法描述行為1，代碼如下：
代碼- public abstract Motor{
- abstract public int getHorsepower();
- }
在Motor抽象類的基礎上構造出多種具體實現，例如A型發動機、B型發動機等，再加上系統的其它部分，最後得到1.0版的軟件並交付使用。一段時間過去了，現在要設計2.0版的軟件。在評估2.0版軟件需求的過程中，發現一小部分發動機是電池驅動的，而電池需要一定的充電時間。銷售部門的人希望能夠通過計算機查閱充電時間。根據這一要求定義一個新的行為，如圖1所示。
行為2：查詢電驅動發動機的充電時間，發動機將返回一個表示充電時間的整數。
用Java方法來描述這個行為，代碼如下：
代碼- public abstract BatteryPoweredMotor extends Motor{
- abstract public int getTimeToRecharge();
- }
在銷售部門的軟件中，電驅動發動機也以類的形式實現，但這些類從BatteryPoweredMotor而不是Motor派生。這些改動加入到2.0版軟件之後，銷售部門很滿意。隨著業務的不斷發展，不久之後光驅動的發動機出現了。銷售部門要求光驅動發動機需要一定光能才能運轉，光能以流明（Lumen）度量。這個信息對客戶很重要，因為下雨或多雲的天氣裏，某些光驅動發動機可能無法運轉。銷售部門要求為軟件增加對光驅動發動機的支持，所以要定義一個新的行為。
行為3：查詢光驅動發動機能夠正常運轉所需要的最小流明數，發動機返回一個整數。
再定義一個抽象類並把行為3轉換成Java方法，代碼如下：
代碼- public abstract SolarPoweredMotor extends Motor{
- abstract public int getLumensToOperate();
- }
如圖1所示，SolarPoweredMotor和BatteryPoweredMotor都從Motor抽象類派生。在整個軟件中，90％以上的代碼以相同的方式對待所有的發動機。偶爾需要檢查一下發動機是光驅動還是電驅動，使用instanceof實現，代碼如下：
代碼- if ( instanceof SolarPoweredMotor){...}
- if ( instanceof BatteryPoweredMotor){...}
無論是哪種發動機，馬力這個參數都很重要，所以在所有派生的抽象類（SolarPoweredMotor和BatteryPoweredMotor）中，getHorsepower()方法都有效。
現在銷售部門又有了一種新的發動機，它是一種既有電驅動又有光驅動的雙重驅動發動機。光驅動和電驅動的行為本身沒有變化，但新的發動機同時支持兩種行為。在考慮如何定義新型的光電驅動發動機時，接口和抽象類的差別開始顯示出來了。新的目標是在增加新型發動機的前提下盡量少改動代碼。因為與光驅動發動機、電驅動發動機有關的代碼已經過全面的測試，不存在已知的Bug。為了增加光電驅動發動機，要定義一個新的SolarBatteryPowered抽象類。如果讓SolarBatteryPowered從Motor抽象類派生，SolarBatteryPowered將不支持針對光驅動發動機和電驅動發動機的instanceof操作。也就是說，如果查詢一個光電驅動的發動機是光驅動的，還是電驅動的，得到的答案是：都不是。
如果讓 SolarBatteryPowered從SolarPoweredMotor（或BatteryPoweredMotor）抽象類派生，類似的問題也會出現，SolarBatteryPowered將不支持針對BatteryPoweredMotor（或SolarPoweredMotor）的 instanceof操作。從行為上看，光電驅動的發動機必須同時從兩個抽象類派生，但Java語言不允許多重繼承。之所以會出現這個問題，根本的原因在於使用抽象類不僅意味著定義特定的行為，而且意味著定義實現的模式。也就是說，應該定義一個發動機如何獲得行為的模型，而不僅僅是聲明發動機具有某一個行為。
通過接口建立行為模型
如果用接口來建立行為模型，就可以避免隱含地規定實現模式。例如，前面的幾個行為改用接口定義如下。
行為1：
代碼- public interface Motor(){
- public int getHorsepower();
- }
行為2：
代碼- public interface BatteryPoweredMotor extends Motor(){
- public int getTimeToRecharge();
- }
行為3：
代碼- public interface SolarPoweredMotor extends Motor{
- abstract public int getLumensToOperate();
- }
現在光電驅動的發動機可以描述為：
代碼- public DualPoweredMotor implements SolarPoweredMotor, BatteryPoweredMotor{}
DualPoweredMotor只繼承行為定義，而不是行為的實現模式，如圖2所示。
在使用接口的同時仍舊可以使用抽象類，不過這時抽象類的作用是實現行為，而不是定義行為。只要實現行為的類遵從接口定義，即使它改變了父抽象類，也不用改變其它代碼與之交互的方式。特別是對於公用的實現代碼，抽象類有它的優點。抽象類能夠保證實現的層次關系，避免代碼重復。然而，即使在使用抽象類的場合，也不要忽視通過接口定義行為模型的原則。從實踐的角度來看，如果依賴於抽象類來定義行為，往往導致過於復雜的繼承關系，而通過接口定義行為能夠更有效地分離行為與實現，為代碼的維護和修改帶來方便。
Java接口特性學習
在Java中看到接口，第一個想到的可能就是C++中的多重繼承和Java中的另外一個關鍵字abstract。從另外一個角度實現多重繼承是接口的功能之一，接口的存在可以使Java中的對象可以向上轉型為多個基類型，並且和抽象類一樣可以防止他人創建該類的對象，因為接口不允許創建對象。
interface關鍵字用來聲明一個接口，它可以產生一個完全抽象的類，並且不提供任何具體實現。interface的特性整理如下：
1. 接口中的方法可以有參數列表和返回類型，但不能有任何方法體。
2. 接口中可以包含字段，但是會被隱式的聲明為static和final。
3. 接口中的字段只是被存儲在該接口的靜態存儲區域內，而不屬於該接口。
4. 接口中的方法可以被聲明為public或不聲明，但結果都會按照public類型處理。
5. 當實現一個接口時，需要將被定義的方法聲明為public類型的，否則為默認訪問類型，Java編譯器不允許這種情況。
6. 如果沒有實現接口中所有方法，那麽創建的仍然是一個接口。
7. 擴展一個接口來生成新的接口應使用關鍵字extends，實現一個接口使用implements。
interface在某些地方和abstract有相似的地方，但是采用哪種方式來聲明類主要參照以下兩點：
1. 如果要創建不帶任何方法定義和成員變量的基類，那麽就應該選擇接口而不是抽象類。
2. 如果知道某個類應該是基類，那麽第一個選擇的應該是讓它成為一個接口，只有在必須要有方法定義和成員變量的時候，才應該選擇抽象類。因為抽象類中允許存在一個或多個被具體實現的方法，只要方法沒有被全部實現該類就仍是抽象類。
以上就是接口的基本特性和應用的領域，但是接口絕不僅僅如此，在Java語法結構中，接口可以被嵌套，既可以被某個類嵌套，也可以被接口嵌套。這在實際開發中可能應用的不多，但也是它的特性之一。需要註意的是，在實現某個接口時，並不需要實現嵌套在其內部的任何接口，而且，private接口不能在定義它的類之外被實現。
最後寫點自己的認識：
這個問題很重要，但是很多人都是工作很久了都是弄不清楚，為什麽呢？這裏不能直接把問題怪到開發者身上，很多人都是直接做的開發中很重要的二次開發或者外包或者是web的開發，所以很多東西都不需要自己去想，而且這樣的工作基本上是很辛苦的，沒有時間接觸，知道了概念但是沒有實踐和真正的思考一切都是白搭，過不了3個月，又會忘記的。
這個問題面試的時候也會很多人問起，有過設計方面的工作內容的人和沒有過類似設計的人的回答還是有所不同的，再結合一些其他類似的問題，面試官假如有心的話還是能看出來一個人之前的工作內容的狀態。
中國的 軟件行業大多數的人都是沒有真正的學透一些語言，比如大多數人都是說語言只是一個工具罷了，有這樣的想法的人更加不會想著去了解這個工具，只是會用就算了。也是因為沒有需要，中國的公司就是這樣了，你想太多也是沒有什麽用，因為工作不需要，你只要按照別人給的接口實現就可以了，沒必要知道為什麽要這樣，到時候他自己會調用我這個接口的，或者我只要按照這種方式配置好就可以了，無所謂所謂的了解什麽架構，了解什麽思想。也許想太多。。。
最後再加上thinking in java中對接口使用原因最根本的指出：為了能夠向上轉型為多個基類型（以及由此而帶來的靈活性）。
當然使用接口還有個原因是和抽象類相同的：防止客戶端程序員創建該類的對象，並確保這僅僅是個建立一個接口。
所以：接口和抽象類，怎麽選？當我們確定某個事物應該成為一個基類的話，接口是第一選擇。
java抽象類與接口的選擇