abstract class和interface

從編程的角度來看，abstract class和interface均可以用來實現"design by contract"的思想。可是在具體的使用上面仍是有一些區別的。

首先，abstract class在Java語言中表示的是一種繼承關係，一個類只能使用一次繼承關係。可是，一個類卻能夠實現多個interface。也許，這是Java語言的設計者在考慮Java對於多重繼承的支持方面的一種折中考慮吧。

其次，在abstract class的定義中，咱們能夠賦予方法的默認行爲。可是在interface的定義中，方法卻不能擁有默認行爲，爲了繞過這個限制，必須使用委託，可是這會 增長一些複雜性，有時會形成很大的麻煩。

在抽象類中不能定義默認行爲還存在另外一個比較嚴重的問題，那就是可能會形成維護上的麻煩。由於若是後來想修改類的界面（通常經過abstract class或者interface來表示）以適應新的狀況（好比，添加新的方法或者給已用的方法中添加新的參數）時，就會很是的麻煩，可能要花費不少的時間（對於派生類不少的狀況，尤其如此）。可是若是界面是經過abstract class來實現的，那麼可能就只須要修改定義在abstract class中的默認行爲就能夠了。

一樣，若是不能在抽象類中定義默認行爲，就會致使一樣的方法實現出如今該抽象類的每個派生類中，違反了"one rule，one place"原則，形成代碼重複，一樣不利於之後的維護。所以，在abstract class和interface間進行選擇時要很是的當心。

回頁首

從設計理念層面看abstract class和interface

上面主要從語法定義和編程的角度論述了abstract class和interface的區別，這些層面的區別是比較低層次的、非本質的。本小節將從另外一個層面：abstract class和interface所反映出的設計理念，來分析一下兩者的區別。做者認爲，從這個層面進行分析才能理解兩者概念的本質所在。

前面已經提到過，abstarct class在Java語言中體現了一種繼承關係，要想使得繼承關係合理，父類和派生類之間必須存在"is a"關係，即父類和派生類在概念本質上應該是相同的（參考文獻〔3〕中有關於"is a"關係的大篇幅深刻的論述，有興趣的讀者能夠參考）。對於interface 來講則否則，並不要求interface的實現者和interface定義在概念本質上是一致的，僅僅是實現了interface定義的契約而已。爲了使論述便於理解，下面將經過一個簡單的實例進行說明。

考慮這樣一個例子，假設在咱們的問題領域中有一個關於Door的抽象概念，該Door具備執行兩個動做open和close，此時咱們能夠經過abstract class或者interface來定義一個表示該抽象概念的類型，定義方式分別以下所示：

使用abstract class方式定義Door：

abstract class Door {
		abstract void open();
		abstract void close()；
}

使用interface方式定義Door：

interface Door {
		void open();
	void close();
}

其餘具體的Door類型能夠extends使用abstract class方式定義的Door或者implements使用interface方式定義的Door。看起來好像使用abstract class和interface沒有大的區別。

若是如今要求Door還要具備報警的功能。咱們該如何設計針對該例子的類結構呢（在本例中，主要是爲了展現abstract class和interface反映在設計理念上的區別，其餘方面無關的問題都作了簡化或者忽略）？下面將羅列出可能的解決方案，並從設計理念層面對這些不一樣的方案進行分析。

解決方案一：

簡單的在Door的定義中增長一個alarm方法，以下：

abstract class Door {
		abstract void open();
		abstract void close()；
		abstract void alarm();
}

或者

interface Door {
		void open();
	void close();
	void alarm();
}

那麼具備報警功能的AlarmDoor的定義方式以下：

class AlarmDoor extends Door {
		void open() { … }
    		void close() { … }
		void alarm() { … }
}

或者

class AlarmDoor implements Door ｛
	void open() { … }
    		void close() { … }
		void alarm() { … }
｝

這種方法違反了面向對象設計中的一個核心原則ISP（Interface Segregation Priciple），在Door的定義中把Door概念自己固有的行爲方法和另一個概念"報警器"的行爲方法混在了一塊兒。這樣引發的一個問題是那些僅僅依賴於Door這個概念的模塊會由於"報警器"這個概念的改變（好比：修改alarm方法的參數）而改變，反之依然。

解決方案二：

既然open、close和alarm屬於兩個不一樣的概念，根據ISP原則應該把它們分別定義在表明這兩個概念的抽象類中。定義方式有：這兩個概念都使用abstract class方式定義；兩個概念都使用interface方式定義；一個概念使用abstract class方式定義，另外一個概念使用interface方式定義。

顯然，因爲Java語言不支持多重繼承，因此兩個概念都使用abstract class方式定義是不可行的。後面兩種方式都是可行的，可是對於它們的選擇卻反映出對於問題領域中的概念本質的理解、對於設計意圖的反映是否正確、合理。咱們一一來分析、說明。

若是兩個概念都使用interface方式來定義，那麼就反映出兩個問題：一、咱們可能沒有理解清楚問題領域，AlarmDoor在概念本質上究竟是Door仍是報警器？二、若是咱們對於問題領域的理解沒有問題，好比：咱們經過對於問題領域的分析發現AlarmDoor在概念本質上和Door是一致的，那麼咱們在實現時就沒有可以正確的揭示咱們的設計意圖，由於在這兩個概念的定義上（均使用interface方式定義）反映不出上述含義。

若是咱們對於問題領域的理解是：AlarmDoor在概念本質上是Door，同時它有具備報警的功能。咱們該如何來設計、實現來明確的反映出咱們的意思呢？前面已經說過，abstract class在Java語言中表示一種繼承關係，而繼承關係在本質上是"is a"關係。因此對於Door這個概念，咱們應該使用abstarct class方式來定義。另外，AlarmDoor又具備報警功能，說明它又可以完成報警概念中定義的行爲，因此報警概念能夠經過interface方式定義。以下所示：

abstract class Door {
		abstract void open();
		abstract void close()；
	}
interface Alarm {
	void alarm();
}
class AlarmDoor extends Door implements Alarm {
	void open() { … }
	void close() { … }
   	void alarm() { … }
}

這種實現方式基本上可以明確的反映出咱們對於問題領域的理解，正確的揭示咱們的設計意圖。其實abstract class表示的是"is a"關係，interface表示的是"like a"關係，你們在選擇時能夠做爲一個依據，固然這是創建在對問題領域的理解上的，好比：若是咱們認爲AlarmDoor在概念本質上是報警器，同時又具備Door的功能，那麼上述的定義方式就要反過來了。