探討接口編程之意義與優勢
接口編程相信大家都知道是怎么回事，下面主要對接口編程的好處進行一些總結。
在項目中的意義：
在傳統的項目開發過程中，由于客戶的需求經常變化，如果不采用面向接口編程，那么我們必須不停改寫現有的業務代碼。改寫代碼可能產生新的BUG，而且改寫代碼還會影響到調用該業務的類，可能全都需要修改，影響系統本身的穩定性。而且為了將改寫代碼帶來的影響最小，我們不得不屈服當前的系統狀況來完成設計，代碼質量和穩定性更低。當這種情況積累到一定程度時，系統就會出現不可預計的錯誤，代碼凌亂，不易讀懂，后接手的人無法讀懂代碼，系統的維護工作越來越重，最終可能導致項目失敗。
接口在項目就是一個業務邏輯，面向接口編程就是先把客戶的業務提取出來，作為接口。業務具體實現通過該接口的實現類來完成。當客戶需求變化時，只需編寫該業務邏輯的新的實現類，通過更改配置文件(例如Spring框架)中該接口的實現類就可以完成需求，不需要改寫現有代碼，減少對系統的影響。
采用基于接口編程的項目，業務邏輯清晰，代碼易懂，方便擴展，可維護性強。即使更換一批人員，新來的人依然可以快速上手。對于公司來說，意義更大。
在Java中的意義：
Java本身也是一個不斷完善的語言，他也在頻繁的改動他的系統API來完善，他的API是一個龐大的體系，互相關聯，如果不采用接口，而都是用實現類的話，那么API的改動就會給整個體系帶來不穩定。而且如果改動API，那么就會有大量采用舊API的項目因無法正常運行，會損失大量客戶。換句話說，JDK已經發布的API是一種承諾，一經發布就不能更改，即使原來API存在各種各樣的問題（例如java.util.Properties類就是一個失敗的例子）也必須保留，于是在Java里就出現了不建議使用的方法，但JDK依然提供該方法。而且Java語言本身是一個跨平臺的語言，為了滿足在各個平臺下運行，就必須把各種操作做成接口，在編寫各個平臺下的實現類。
設計模式的體現：
在設計模式的原則里的開閉原則，其實就是要使用接口來實現對擴展開放，對修改關閉。在設計模式的其他原則里也有關于基于接口編程的原則，即依賴倒轉的設計原則(DIP)----高層模塊不應該依賴于底層模塊。二者都應該依賴于抽象；抽象不應該依賴于細節，細節應該依賴于抽象(注：來自《敏捷軟件開發--原則、模式與實踐》Robert C.Martin著)。在使用面向接口的編程過程中，將具體邏輯與實現分開，減少了各個類之間的相互依賴，當各個類變化時，不需要對已經編寫的系統進行改動，添加新的實現類就可以了，不在擔心新改動的類對系統的其他模塊造成影響。
編程也是一門藝術，在C語言中靈活的使用指針是一門藝術，在面對對象的程序中，靈活的使用接口也是一門藝術。現在項目中，功能越來越復雜，只設計了***的類，對于整個系統來說沒有多大意義，現在的項目更注重各個功能模塊的整合及可維護性，接口的設計就顯得更為重要了。程序設計不再是設計類的具體實現，而是從整個項目出發，設計出可擴展性強的接口。當你發現越來越靈活的使用接口時，那么你就從程序員升級為架構師了。可惜我現在依然是一名程序員，正在像架構師努力。
在一些大型項目或者大型公司里，都是由架構師編寫出系統接口，具體的實現類交給了程序員編寫，公司越大這種情況越明顯，所以在這些公司里做開發，我們可能都不知道編寫出的系統是個什么樣子，每天做的工作可能就是做“填空題”了。建議大家閱讀敏《捷軟件開發--原則、模式與實踐》Robert C.Martin著這本書，那么對如何進行接口編程就會有一個新的認識了。
***，希望大家都能成為一個優秀的系統架構師。
我記得我曾經在一篇帖子中提到過，一個接口可以從三方面去考察：
制定者（或者叫協調者），實現者（或者叫生產者），調用者（或者叫消費者）。
接口本質上就是由制定者來協調實現者和調用者之間的關系。
所以通常說的“面向接口編程”可以理解為：
只有實現者和調用者都遵循“面向接口編程”這個準則，制定者的協調目的才能達到。
一個老生常談的例子就是JDBC。
優點：
接口和實現分離了，適于團隊的協作開發。
更具體的優點：可以參看IDP原則。
缺點：
設計難了，在你沒有寫實現的時候，就得想好接口，接口一變，全部亂套，這就是所謂的設計比實現難。
所以設計接口的人工資都高啊！！！
【相關閱讀】
