在專案中的意義： 
   在傳統的專案開發過程中，由於客戶的需求經常變化，如果不採用面向介面程式設計，那麼我們必須不停改寫現有的業務程式碼。改寫程式碼可能產生新的BUG，而且改寫程式碼還會影響到呼叫該業務的類，可能全都需要修改，影響系統本身的穩定性。而且為了將改寫程式碼帶來的影響最小，我們不得不屈服當前的系統狀況來完成設計，程式碼質量和穩定性更低。當這種情況積累到一定程度時，系統就會出現不可預計的錯誤，程式碼凌亂，不易讀懂，後接手的人無法讀懂程式碼，系統的維護工作越來越重，最終可能導致專案失敗。 
介面在專案就是一個業務邏輯，面向介面程式設計就是先把客戶的業務提取出來，作為介面。業務具體實現通過該介面的實現類來完成。當客戶需求變化時，只需編寫該業務邏輯的新的實現類，通過更改配置檔案(例如Spring框架)中該介面的實現類就可以完成需求，不需要改寫現有程式碼，減少對系統的影響。 採用基於介面程式設計的專案，業務邏輯清晰，程式碼易懂，方便擴充套件，可維護性強。即使更換一批人員，新來的人依然可以快速上手。對於公司來說，意義更大。 
在Java中的意義： 
   Java本身也是一個不斷完善的語言，他也在頻繁的改動他的系統API來完善，他的API是一個龐大的體系，互相關聯，如果不採用介面，而都是用實現類的話，那麼API的改動就會給整個體系帶來不穩定。而且如果改動API，那麼就會有大量採用舊API的專案因無法正常執行，會損失大量客戶。換句話說，JDK已經發布的API是一種承諾，一經發布就不能更改，即使原來API存在各種各樣的問題（例如java.util.Properties類就是一個失敗的例子）也必須保留，於是在Java裡就出現了不建議使用的方法，但JDK依然提供該方法。而且Java語言本身是一個跨平臺的語言，為了滿足在各個平臺下執行，就必須把各種操作做成介面，在編寫各個平臺下的實現類。 
設計模式的體現： 
   在設計模式的原則裡的開閉原則，其實就是要使用介面來實現對擴充套件開放，對修改關閉。在設計模式的其他原則裡也有關於基於介面程式設計的原則，即依賴倒轉的設計原則(DIP)----高層模組不應該依賴於底層模組。二者都應該依賴於抽象；抽象不應該依賴於細節，細節應該依賴於抽象(注：來自《敏捷軟體開發--原則、模式與實踐》Robert C.Martin著)。在使用面向介面的程式設計過程中，將具體邏輯與實現分開，減少了各個類之間的相互依賴，當各個類變化時，不需要對已經編寫的系統進行改動，新增新的實現類就可以了，不在擔心新改動的類對系統的其他模組造成影響。 
介面本質上就是由制定者來協調實現者和呼叫者之間的關係。 
所以通常說的“面向介面程式設計”可以理解為： 
只有實現者和呼叫者都遵循“面向介面程式設計”這個準則，制定者的協調目的才能達到。 
一個老生常談的例子就是JDBC。 
優點： 
介面和實現分離了，適於團隊的協作開發。 
主要為了實現鬆散耦合的系統，便於以後升級，擴充套件。