接口与抽象类的使用选择
為什么有的地方必須使用接口而不是抽象類，而在另一些地方，又必須使用抽象類而不是接口呢？或者說，在考慮Java類的一般化問題時，很多人會在接口和抽象類之間猶豫不決，甚至隨便選擇一種。
?
首先來了解一下接口和抽象類的一些具體的區(qū)別:
抽象類表示該類中可能已經(jīng)有一些方法的具體定義，但是接口就僅僅只能定義各個方法的界面(方法名，參數(shù)列表，返回類型)，并不關心具體細節(jié)。
?
? ?? 類描述了一個實體，包括實體的狀態(tài)，也包括實體可能發(fā)出的動作。?
接口定義了一個實體可能發(fā)出的動作。但是只是定義了這些動作的原型，沒有實現(xiàn)，也沒有任何狀態(tài)信息。?
所以接口有點象一個規(guī)范、一個協(xié)議，是一個抽象的概念；而類則是實現(xiàn)了這個協(xié)議，滿足了這個規(guī)范的具體實體，是一個具體的概念。?
從程序角度，簡單理解，接口就是函數(shù)聲明，類就是函數(shù)實現(xiàn)。需要注意的是同一個聲明可能有很多種實現(xiàn)。?
1、接口中定義類方法的原型，但是不能說是空方法，因為空方法的意思是有實現(xiàn)體，只不過實現(xiàn)體是空操作。實際上接口沒有定義任何實現(xiàn)體。具體的實現(xiàn)體都是在實現(xiàn)接口的類中，接口只是定義了這些方法的調用方式。?
你當然也可以不用接口，直接在類里面寫方法，但是如果你的一組方法需要在很多類里實現(xiàn)，那么把它們抽象出來，做成一個接口規(guī)范，不是更好么？?
2、一個類描述了一個實體，這個實體可能是一個復雜的對象，它的動作很多，如果把這些動作分類，用接口a定義其中的某一組動作，接口b定義其中的另外一組動作，這樣的結構，比較清楚。?
這種方式具備了多繼承的優(yōu)點，避免了多繼承的缺陷。實際上在歷史上，接口在很大程度上，是為了解決多繼承帶來的種種問題而設計出來的。?
3、包中那些已定義的接口，怎么知道那里面定義了什么方法。?
接口里定義了方法的輸入輸出，這些都是協(xié)議，具體的實現(xiàn)都在每個類中。對于很多只需要抽象接口的地方，不需要知道具體的類是什么，只要這個類實現(xiàn)了這個接口就可以了。
?
?
實際上接口和抽象類的選擇不是隨心所欲的。 要理解接口和抽象類的選擇原則，有兩個概念很重要：對象的行為和對象的實現(xiàn)。如果一個實體可以有多種實現(xiàn)方式，則在設計實體行為的描述方式時，應當達到這 樣一個目標：在使用實體的時候，無需詳細了解實體行為的實現(xiàn)方式。也就是說，要把對象的行為和對象的實現(xiàn)分離開來。既然Java的接口和抽象類都可以定義 不提供具體實現(xiàn)的方法，在分離對象的行為和對象的實現(xiàn)時，到底應該使用接口還是使用抽象類呢？?
通過抽象類建立行為模型
在接口和抽象類的選擇上，必須遵守這樣一個原則：行為模型應該總是通過接口而不是抽象類定義。為了說明其原因，下面試著通過抽象類建立行為模型，看看會出現(xiàn)什么問題。?
假設要為銷售部門設計一個軟件，這個軟件包含一個“發(fā)動機”（Motor）實體。顯然無法在發(fā)動機對象中詳細地描述發(fā)動機的方方面面，只能描述某些對當前軟件來說重要的特征。至于發(fā)動機的哪些特征是重要的，則要與用戶（銷售部門）交流才能確定。?
銷售部門的人要求每一個發(fā)動機都有一個稱為馬力的參數(shù)。對于他們來說，這是惟一值得關心的參數(shù)。基于這一判斷，可以把發(fā)動機的行為定義為以下行為。
行為1：查詢發(fā)動機的馬力，發(fā)動機將返回一個表示馬力的整數(shù)。?
雖然現(xiàn)在還不清楚發(fā)動機如何取得馬力這個參數(shù)，但可以肯定發(fā)動機一定支持這個行為，而且這是所有發(fā)動機惟一值得關注的行為特征。這個行為特征既可 以用接口定義，也可以用抽象類定義。為了說明用抽象類定義可能出現(xiàn)的問題，下面用抽象類建立發(fā)動機的行為模型，并用Java方法描述行為1，代碼如下：?
public abstract Motor{
abstract public int getHorsepower();?
}
在Motor抽象類的基礎上構造出多種具體實現(xiàn)，例如A型發(fā)動機、B型發(fā)動機等，再加上系統(tǒng)的其它部分，最后得到1.0版的軟件并交付使用。一段 時間過去了，現(xiàn)在要設計2.0版的軟件。在評估2.0版軟件需求的過程中，發(fā)現(xiàn)一小部分發(fā)動機是電池驅動的，而電池需要一定的充電時間。銷售部門的人希望 能夠通過計算機查閱充電時間。根據(jù)這一要求定義一個新的行為，如圖1所示。?
行為2：查詢電驅動發(fā)動機的充電時間，發(fā)動機將返回一個表示充電時間的整數(shù)。?
用Java方法來描述這個行為，代碼如下：?
public abstract BatteryPoweredMotor extends Motor{
abstract public int getTimeToRecharge();
}
在銷售部門的軟件中，電驅動發(fā)動機也以類的形式實現(xiàn)，但這些類從BatteryPoweredMotor而不是Motor派生。這些改動加入到 2.0版軟件之后，銷售部門很滿意。隨著業(yè)務的不斷發(fā)展，不久之后光驅動的發(fā)動機出現(xiàn)了。銷售部門要求光驅動發(fā)動機需要一定光能才能運轉，光能以流明 （Lumen）度量。這個信息對客戶很重要，因為下雨或多云的天氣里，某些光驅動發(fā)動機可能無法運轉。銷售部門要求為軟件增加對光驅動發(fā)動機的支持，所以 要定義一個新的行為。
行為3：查詢光驅動發(fā)動機能夠正常運轉所需要的最小流明數(shù)，發(fā)動機返回一個整數(shù)。?
再定義一個抽象類并把行為3轉換成Java方法，代碼如下：
public abstract SolarPoweredMotor extends Motor{
abstract public int getLumensToOperate();
}?
?
?
如圖1所示，SolarPoweredMotor和BatteryPoweredMotor都從Motor抽象類派生。在整個軟件中，90％以上 的代碼以相同的方式對待所有的發(fā)動機。偶爾需要檢查一下發(fā)動機是光驅動還是電驅動，使用instanceof實現(xiàn)，代碼如下：?
[color=#336600]
if (instanceof SolarPoweredMotor){...}?
if (instanceof BatteryPoweredMotor){...}
無論是哪種發(fā)動機，馬力這個參數(shù)都很重要，所以在所有派生的抽象類（SolarPoweredMotor和BatteryPoweredMotor）中，getHorsepower()方法都有效。
現(xiàn)在銷售部門又有了一種新的發(fā)動機，它是一種既有電驅動又有光驅動的雙重驅動發(fā)動機。光驅動和電驅動的行為本身沒有變化，但新的發(fā)動機同時支持兩 種行為。在考慮如何定義新型的光電驅動發(fā)動機時，接口和抽象類的差別開始顯示出來了。新的目標是在增加新型發(fā)動機的前提下盡量少改動代碼。因為與光驅動發(fā) 動機、電驅動發(fā)動機有關的代碼已經(jīng)過全面的測試，不存在已知的Bug。為了增加光電驅動發(fā)動機，要定義一個新的SolarBatteryPowered抽 象類。如果讓SolarBatteryPowered從Motor抽象類派生，SolarBatteryPowered將不支持針對光驅動發(fā)動機和電驅動 發(fā)動機的instanceof操作。也就是說，如果查詢一個光電驅動的發(fā)動機是光驅動的，還是電驅動的，得到的答案是：都不是。?
如果讓SolarBatteryPowered從SolarPoweredMotor（或BatteryPoweredMotor）抽象類派生， 類似的問題也會出現(xiàn)，SolarBatteryPowered將不支持針對BatteryPoweredMotor（或 SolarPoweredMotor）的instanceof操作。從行為上看，光電驅動的發(fā)動機必須同時從兩個抽象類派生，但Java語言不允許多重繼 承。之所以會出現(xiàn)這個問題，根本的原因在于使用抽象類不僅意味著定義特定的行為，而且意味著定義實現(xiàn)的模式。也就是說，應該定義一個發(fā)動機如何獲得行為的 模型，而不僅僅是聲明發(fā)動機具有某一個行為。?
通過接口建立行為模型
如果用接口來建立行為模型，就可以避免隱含地規(guī)定實現(xiàn)模式。例如，前面的幾個行為改用接口定義如下。?
行為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();
}
現(xiàn)在光電驅動的發(fā)動機可以描述為：
public DualPoweredMotor implements SolarPoweredMotor, BatteryPoweredMotor{}
?
DualPoweredMotor只繼承行為定義，而不是行為的實現(xiàn)模式，?
在使用接口的同時仍舊可以使用抽象類，不過這時抽象類的作用是實現(xiàn)行為，而不是定義行為。只要實現(xiàn)行為的類遵從接口定義，即使它改變了父抽象類， 也不用改變其它代碼與之交互的方式。特別是對于公用的實現(xiàn)代碼，抽象類有它的優(yōu)點。抽象類能夠保證實現(xiàn)的層次關系，避免代碼重復。然而，即使在使用抽象類 的場合，也不要忽視通過接口定義行為模型的原則。從實踐的角度來看，如果依賴于抽象類來定義行為，往往導致過于復雜的繼承關系，而通過接口定義行為能夠更 有效地分離行為與實現(xiàn)，為代碼的維護和修改帶來方便。
轉載于:https://www.cnblogs.com/hoobey/p/6534173.html
總結
以上是生活随笔為你收集整理的接口与抽象类的使用选择的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 二进制补码
- 下一篇： GIT入门笔记（4）- GIT 安装