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