abstract class和interface是Java語言中對於抽象類定義進行支持的兩種機制
正是由於這兩種機制的存在
才賦予了Java強大的面向對象能力
abstract class和interface之間在對於抽象類定義的支持方面具有很大的相似性
甚至可以相互替換
因此很多開發者在進行抽象類定義時對於abstract class和interface的選擇顯得比較隨意
其實
兩者之間還是有很大的區別的
對於它們的選擇甚至反映出對於問題領域本質的理解
對於設計意圖的理解是否正確
合理
本文將對它們之間的區別進行一番剖析
試圖給開發者提供一個在二者之間進行選擇的依據
理解抽象類
在面向對象的概念中
我們知道所有的對象都是通過類來描繪的
但是反過來卻不是這樣
並不是所有的類都是用來描繪對象的
如果一個類中沒有包含足夠的信息來描繪一個具體的對象
這樣的類就是抽象類
抽象類往往用來表征我們在對問題領域進行分析
設計中得出的抽象概念
是對一系列看上去不同
但是本質上相同的具體概念的抽象
比如
如果我們進行一個圖形編輯軟件的開發
就會發現問題領域存在著圓
三角形這樣一些具體概念
它們是不同的
但是它們又都屬於形狀這樣一個概念
形狀這個概念在問題領域是不存在的
它就是一個抽象概念
正是因為抽象的概念在問題領域沒有對應的具體概念
所以用以表征抽象概念的抽象類是不能夠實例化的
下面從三個方面進行比較
一從語法定義層面看abstract class和interface
在語法層面
Java語言對於abstract class和interface給出了不同的定義方式
下面以定義一個名為Demo的抽象類為例來說明這種不同
使用abstract class的方式定義Demo抽象類的方式如下
abstract class Demo {
abstract void method
（）
abstract void method
（）
…
}
使用interface的方式定義Demo抽象類的方式如下
interface Demo {
void method
（）
void method
（）
…
}
在abstract class方式中
Demo可以有自己的數據成員
也可以有非abstarct的成員方法
而在interface方式的實現中
Demo只能夠有靜態的不能被修改的數據成員（也就是必須是static final的
不過在interface中一般不定義數據成員）
所有的成員方法都是abstract的
從某種意義上說
interface是一種特殊形式的abstract class
二從編程層面看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
關系
即父類和派生類在概念本質上應該是相同的（參考文獻〔
〕中有關於
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的功能
那麼上述的定義方式就要反過來了
結論
abstract class和interface是Java語言中的兩種定義抽象類的方式
它們之間有很大的相似性
但是對於它們的選擇卻又往往反映出對於問題領域中的概念本質的理解
對於設計意圖的反映是否正確
合理
因為它們表現了概念間的不同的關系（雖然都能夠實現需求的功能）
這其實也是語言的一種的慣用法
希望讀者朋友能夠細細體會
在面向對象的概念中
我們知道所有的對象都是通過類來描繪的
但是並不是所有的類都是用來描繪對象的
如果一個類中沒有包含足夠的信息來描繪一個具體的對象
這樣的類就是抽象類
抽象類往往用來表征我們在對問題領域進行分析
設計中得出的抽象概念
是對一系列看上去不同
但是本質上相同的具體概念的抽象
我們不能把它們實例化（拿不出一個具體的東西）所以稱之為抽象
比如
我們要描述
水果
它就是一個抽象
它有質量
體積等一些共性（水果有質量）
但又缺乏特性（蘋果
橘子都是水果
它們有自己的特性）
我們拿不出唯一一種能代表水果的東西（因為蘋果
橘子都不能代表水果）
可用抽象類來描述它
所以抽象類是不能夠實例化的
當我們用某個類來具體描述
蘋果
時
這個類就可以繼承描述
水果
的抽象類
我們都知道
蘋果
是一種
水果
在面向對象領域
抽象類主要用來進行類型隱藏
我們可以構造出一個固定的一組行為的抽象描述
但是這組行為卻能夠有任意個可能的具體實現方式
這個抽象描述就是抽象類
而這一組任意個可能的具體實現則表現為這個抽象類的所有派生類
接口和抽象類中的所有抽象方法不能有具體實現
而應在它們的子類中實現所有的抽象方法（要有函數體
哪怕{ }裡是空的）
java的設計者可能為抽象方法的靈活性考慮
每個子類可根據自己的需要來實現抽象方法
抽象類（abstract class）的定義方式如下
public abstract class AbstractClass //裡面至少有一個抽象方法
{
public int t; //普通數據成員
public abstract void method
（）
//抽象方法
抽象類的子類在類中必須實現抽象類中的抽象方法
public abstract void method
（）
public void method
（）
//非抽象方法
public int method
（）
publi int method
（）{
…… //抽象類中可以賦予非抽象方法方法的默認行為
即方法的具體實現
}
public void method
（）{
…… //抽象類中可以賦予非抽象方法方法的默認行為
即方法的具體實現
}
}
接口（interface）的定義方式如下
public interface Interface
{
static final int i; //接口中不能有普通數據成員
只能夠有靜態的不能被修改的數據成員
static表示全局
final表示不可修改
可以不用static final 修飾
會隱式的聲明為static和final
public void method
（）
//接口中的方法一定是抽象方法
所以不用abstract修飾
public void method
（）
//接口中不能賦予方法的默認行為
即不能有方法的具體實現
}
簡言之抽象類是一種功能不全的類
接口只是一個抽象方法聲明和靜態不能被修改的數據的集合
兩者都不能被實例化
從某種意義上說
接口是一種特殊形式的抽象類
在java語言中抽象類表示的是一種繼承關系
一個類只能繼承繼承一個抽象類
而一個類卻可以實現多個接口
在許多情況下
接口確實可以代替抽象類
如果你不需要刻意表達屬性上的繼承的話
進一步理解
關於java引入抽象類
接口的目的
向高手請教得到的答復如下
從類的層次結構上看
抽象類是在層次的頂端
但在實際的設計當中
一般來說抽象類應當是後面才會出現
為什麼？實際上抽象類的獲取有點像數學中的提取公因式
ax+bx
x就是抽象類
如果你沒有前面的式子
你怎麼知道x是不是公因式呢？在這點上
也符合人們認識世界的過程
先具體後抽象
因此在設計過程中如果你得到大量的具體概念並從當中找到其共性時
這個共性的集合就是抽象類應當是沒錯的
interface從表面上看
和抽象類很相似
但用法完全不同
它的基本功能就是把一些毫不相關的類（概念）集合在一起形成一個新的
可集中操作的
新類
我給學生的一個典型例子就是
司機
誰可以當司機？誰都可以
只要領取了駕照
所以我不管你是學生
白領
藍領還是老板
只要有駕照就是司機
interface DriverLicence {
Licence getLicence（）
}
class StudentDriver extends Student implements DriverLicence {
}
class WhtieCollarEmployeeDriver extends WhtieCollarEmployee implements DriverLicence {
}
class BlueCollarEmployeeDriver extends BlueCollarEmployee implements DriverLicence {
}
class BossDriver extends Boss implements Driver {
}
當我定義了
汽車
類後
我就可以指定
司機
了
class Car {
setDriver（DriverLicence driver）
}
這時候
Car的對象並不關心這個司機到底是干什麼的
他們的唯一共同點是領取了駕照（都實現了DriverLicence接口）
這個
應當是接口最強大的地方也是抽象類無法比擬的
總結
抽象類是提取具體類的公因式
而接口是為了將一些不相關的類
雜湊
成一個共同的群體
通常我們平時養成良好的習慣就是多用接口
畢竟java是單繼承
不像C++
但是在需要使用抽象類的時候一定還是要用的（有點類似goto的用法）
From:http://tw.wingwit.com/Article/program/Java/hx/201311/26194.html
