abstract class和interface的使用場景分別是什麼？

abstract class和interface是Java語言中對於抽象類定義進行支持的兩種機制，正是因爲這兩種機制的存在，才賦予了Java強大的面向對象能力。abstract class和interface之間在對於抽象類定義的支持方面具備很大的類似性，甚至能夠相互替換，所以不少開發者在進行抽象類定義時對於abstract class和interface的選擇顯得比較隨意。其實，二者之間仍是有很大區別的，對於它們的選擇甚至反映出對於問題領域本質的理解、對於設計意圖的理解是否正確、合理。我認爲正確運用好抽象類和接口，能夠優化軟件結構的設計，對軟件的擴展、維護帶來很大的便利。本文將對它們之間的區別進行一番剖析，試圖給開發者提供一個在兩者之間進行選擇的依據。

首先來理解一下抽象類。在面向對象的概念中，咱們知道全部的對象都是經過類來描繪的，若是一個類中沒有包含足夠的信息來描繪一個具體的對象，這樣的類就是抽象類。抽象類每每用來表徵咱們在對問題領域進行分析、設計中得出的抽象概念，是對一系列看上去不一樣，可是本質上相同的具體概念的抽象。好比咱們xpads 項目中的交易類就能夠理解爲一個抽象類，即期交易、遠期交易、掉期交易等都是繼承交易類的具體類。即期交易、遠期交易、掉期交易這些具體概念是實際存在的，而交易這個概念在問題領域中是不存在的，能夠理解爲一個抽象概念。正是由於抽象概念在實際問題領域中沒有東西與它對應，因此用以表徵抽象概念的抽象類是不能被實例化的。

接下來理解一下接口，接口是面向對象設計中的一組規範，是一組方法的集合體（也能夠定義一些常量），在一些軟件設計模式中提倡的面向接口編程，其實就是屏蔽實現類的內部處理，加強模塊的安全性、靈活性，達到軟件設計的高內聚、鬆耦合。

下面從三個方面進行比較：

1、從語法定義層面看abstract class和interface

使用abstract class的方式定義Deal抽象類的方式以下：

abstract class  FxDeal ｛

                           private long dealsId;  //交易流水號

private long blockNumber;//套流水號

private String appls;//產品類別

private String inputChannel;//錄入渠道

private String typeOfDeal;//交易類型

private String flagOfDeal;// 特殊交易標識

private String bankId;//業務發生行

private String customerId; //客戶號

private String customerName;//客戶名稱

private int customerType;//客戶類型

private double amount1;

private double amount2;

　abstract void method1();

abstract void method2();

               …

｝

使用interface的方式定義Deal抽象類的方式以下：
　　interface FxDeal {
　　void method1();
　　void method2();
　　…
　　}

在abstract class方式中，Deal能夠有本身的數據成員，也能夠有非abstarct的成員方法，而在interface方式的實現中，Deal只可以有靜態的不能被修改的數據成員（也就是必須是static final的，不過在interface中通常不定義數據成員），全部的成員方法都是abstract的。從某種意義上說，interface是一種特殊形式的abstract class。

2、從編程層面看abstract class和interface

首先，abstract class在Java語言中表示的是一種繼承關係，一個類只能使用一次繼承關係。可是，一個類卻能夠實現多個interface。

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

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

另外一個問題是：若是不是採用抽象類中的默認行爲，就會致使一樣的方法實現出如今該抽象類（或接口）的每個派生類（或實現類）中，違反了「one rule，one place」原則，形成代碼重複，一樣不利於之後的維護。所以，我認爲在abstract class和interface間進行選擇時仍是須要謹慎的，搞很差的話，是會給程序埋下一些隱患的。

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

         abstract class在Java語言中體現的是一種繼承關係，父類和派生類之間必須存在「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方式來定義，那麼就反映出兩個問題：1、咱們可能沒有理解清楚問題領域，AlarmDoor在概念本質上究竟是Door仍是報警器？2、若是咱們對於問題領域的理解沒有問題，好比：咱們經過對於問題領域的分析發現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的功能，那麼上述的定義方式就要反過來了。其實在某些時候，這兩個特殊的類的使用是能夠互爲替換的，可是在較大規模的系統工程設計時，若是不能正確運用好它的話，可能會破壞程序的結構，加強模塊間的耦合度，給程序的維護與升級帶來較大的不便，但願你們可以細細體會。