在壹個面向對象的系統中，系統的各種功能是由許許多多的不同對象協作完成的。在這種情況下，各個對象內部是如何實現自己的,對系統設計人員來講就不那麽重要了；而各個對象之間的協作關系則成為系統設計的關鍵。小到不同類之間的通信，大到各模塊之間的交互，在系統設計之初都是要著重考慮的，這也是系統設計的主要工作內容。面向接口編程就是指按照這種思想來編程。
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編程，原意是指面向抽象協議編程，實現者在實現時要嚴格按協議來辦。面向對象編程是指面向抽象和具象。抽象和具象是矛盾的統壹體，不可能只有抽象沒有具象。壹般懂得抽象的人都明白這個道理。 但有的人只知具象卻不知抽象為何物。所以只有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();