一篇非常經典的文章（面向介面程式設計）
什麼叫面向介面程式設計
在一個面向物件的系統中，系統的各種功能是由許許多多的不同物件協作完成的。在這種情況下，各個物件內部是如何實現自己的對系統設計人員來講就不那麼重要了；而各個物件之間的協作關係則成為系統設計的關鍵。小到不同類之間的通訊，大到各模組之間的互動，在系統設計之初都是要著重考慮的，這也是系統設計的主要工作內容。面向介面程式設計我想就是指按照這種思想來程式設計吧！實際上，在日常工作中，你已經按照介面程式設計了，只不過如果你沒有這方面的意識，那麼你只是在被動的實現這一思想；表現在頻繁的抱怨別人改的程式碼影響了你（介面沒有設計到），表現在某個模組的改動引起其他模組的大規模調整（模組介面沒有很好的設計）等等。
Booch先生那天談到Interaction Designer，它就是指做這類設計的人，只不過層次更高一些。我想目前我們的軟體設計隊伍中，這類人是最缺乏的人才之一。
非介面程式設計？是不是就是面向過程的程式設計思想？
1.關於介面的理解。
介面從更深層次的理解，應是定義（規範，約束）與實現（名實分離的原則）的分離。
我們在一般實現一個系統的時候，通常是將定義與實現合為一體，不加分離的，我認為最為理解的系統設計規範應是所有的定義與實現分離，儘管這可能對系統中的某些情況有點繁煩。
介面的本身反映了系統設計人員對系統的抽象理解。
介面應有兩類：
第一類是對一個體的抽象，它可對應為一個抽象體(abstract class)；
第二類是對一個體某一方面的抽象，即形成一個抽象面（interface）；
一個體有可能有多個抽象面。
抽象體與抽象面是有區別的。
2.設計介面的另一個不可忽視的因素是介面所處的環境(context,environment)，系統論的觀點：環境是系統要素所處的空間與外部影響因素的總和。任何介面都是在一定的環境中產生的。因此環境的定義及環境的變化對介面的影響是不容忽視的，脫離原先的環境，所有的介面將失去原有的意義。
3.按照元件的開發模型（3C），它們三者相輔相成，各司一面，渾然一體，缺一不可。
面向物件是指，我們考慮問題時，以物件為單位，考慮它的屬性及方法
面向過程是指，我們考慮問題時，以一個具體的流程（事務過程）為單位，考慮它的實現
介面設計與非介面設計是針對複用技術而言的，與面向物件（過程）不是一個問題
我認為：UML裡面所說的interface是協議的另一種說法。並不是指com的interface，CORBA的interface，Java的interface，Delphi的interface，人機介面的interface或NIC的interface。
在具體實現中，是可以把UML的interface實現為語言的interface，分散式物件環境的interface或其它什麼interface，但就理解UML的interface而言，指的是系統每部分的實現和實現之間，通過interface所確定的協議來共同工作。
所以我認為，面向interface程式設計，原意是指面向抽象協議程式設計，實現者在實現時要嚴格按協議來辦。也就是BillJoy同志說的，一邊翻rfc，一邊寫程式碼的意思。面向物件程式設計是指面向抽象和具象。抽象和具象是矛盾的統一體，不可能只有抽象沒有具象。一般懂得抽象的人都明白這個道理。 但有的人只知具象卻不知抽象為何物。
所以只有interface沒有實現，或只有實現而沒有interface者是沒有用的，反OO的。
所以還是老老實實面向物件程式設計，面向協議程式設計，或者什麼都不面向，老老實實程式設計。
但是我很討厭討論這樣的術語，不如我們談談什麼叫面向領導的程式設計？面向使用者的程式設計？領導和使用者有時都很BT，我們就面向BT程式設計？
選擇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：
程式碼
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();
}
現在光電驅動的發動機可以描述為：
程式碼
public DualPoweredMotor implements SolarPoweredMotor, BatteryPoweredMotor{}
DualPoweredMotor只繼承行為定義，而不是行為的實現模式，如圖2所示。
在使用介面的同時仍舊可以使用抽象類，不過這時抽象類的作用是實現行為，而不是定義行為。只要實現行為的類遵從介面定義，即使它改變了父抽象類，也不用改變其它程式碼與之互動的方式。特別是對於公用的實現程式碼，抽象類有它的優點。抽象類能夠保證實現的層次關係，避免程式碼重複。然而，即使在使用抽象類的場合，也不要忽視通過介面定義行為模型的原則。從實踐的角度來看，如果依賴於抽象類來定義行為，往往導致過於複雜的繼承關係，而通過介面定義行為能夠更有效地分離行為與實現，為程式碼的維護和修改帶來方便。
從這個例子上來看,是介面和抽象類的區別導致設計上的不同. 一個類可以實現多個介面,但是不能實現多個抽象類.一個java類只能繼承一個父類.
行為模型要通過介面定義而不是抽象類. 抽象類結合介面使用,抽象類的作用是實現行為,而不是定義行為.
Java介面特性學習
在Java中看到介面，第一個想到的可能就是C++中的多重繼承和Java中的另外一個關鍵字abstract。從另外一個角度實現多重繼承是介面的功能之一，介面的存在可以使Java中的物件可以向上轉型為多個基型別，並且和抽象類一樣可以防止他人建立該類的物件，因為介面不允許建立物件。
interface關鍵字用來宣告一個介面，它可以產生一個完全抽象的類，並且不提供任何具體實現。interface的特性整理如下：
1. 介面中的方法可以有引數列表和返回型別，但不能有任何方法體。
2. 介面中可以包含欄位，但是會被隱式的宣告為static和final。
3. 介面中的欄位只是被儲存在該介面的靜態儲存區域內，而不屬於該介面。
4. 介面中的方法可以被宣告為public或不宣告，但結果都會按照public型別處理。
5. 當實現一個介面時，需要將被定義的方法宣告為public型別的，否則為預設訪問型別，Java編譯器不允許這種情況。
6. 如果沒有實現介面中所有方法，那麼建立的仍然是一個介面。
7. 擴充套件一個介面來生成新的介面應使用關鍵字extends，實現一個介面使用implements。
interface在某些地方和abstract有相似的地方，但是採用哪種方式來宣告類主要參照以下兩點：
1. 如果要建立不帶任何方法定義和成員變數的基類，那麼就應該選擇介面而不是抽象類。
2. 如果知道某個類應該是基類，那麼第一個選擇的應該是讓它成為一個介面，只有在必須要有方法定義和成員變數的時候，才應該選擇抽象類。因為抽象類中允許存在一個或多個被具體實現的方法，只要方法沒有被全部實現該類就仍是抽象類。
以上就是介面的基本特性和應用的領域，但是介面絕不僅僅如此，在Java語法結構中，介面可以被巢狀，既可以被某個類巢狀，也可以被介面巢狀。這在實際開發中可能應用的不多，但也是它的特性之一。需要注意的是，在實現某個介面時，並不需要實現巢狀在其內部的任何介面，而且，private介面不能在定義它的類之外被實現。