介面的行為抽象和抽象類的行為抽象

自在现实發表於2024-06-25

選擇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:

Java程式碼

  1. public interface Motor(){

  2. public int getHorsepower();

  3. }

行為2:

Java程式碼

  1. public interface BatteryPoweredMotor extends Motor(){ 2. public int getTimeToRecharge();

  2. }

行為3:

Java程式碼

  1. public interface SolarPoweredMotor extends Motor{

  2. abstract public int getLumensToOperate();

  3. }

現在光電驅動的發動機可以描述為:

Java程式碼

  1. public DualPoweredMotor implements SolarPoweredMotor,

BatteryPoweredMotor{}

DualPoweredMotor只繼承行為定義,而不是行為的實現模式,如圖2所示。

在使用介面的同時仍舊可以使用抽象類,不過這時抽象類的作用是實現行為,而不是定義行為。只要實現行為的類遵從介面定義,即使它改變了父抽象類,也不用改變其它程式碼與之互動的方式。特別是對於公用的實現程式碼,抽象類有它的優點。抽象類能夠保證實現的層次關係,避免程式碼重複。然而,即使在使用抽象類的場合,也不要忽視透過介面定義行為模型的原則。從實踐的角度來看,如果依賴於抽象類來定義行為,往往導致過於複雜的繼承關係,而透過介面定義行為能夠更有效地分離行為與實現,為程式碼的維護和修改帶來方便。

相關文章