1 什麼是接口
接口是一種用來定義程序的協議，它描述可屬於任何類或結構的一組相關行為。
接口是一組規則的集合，它規定了實現本接口的類或接口必須擁有的一組規則。體現了自然界“如果你是……則必須能……”的理念。
接口是在一定粒度視圖上同類事物的抽象表示。因為“同類事物”這個概念是相對的，它因為粒度視圖不同而不同。
2 為什麼要使用接口？而不是直接實現呢？
接口的使用並非總是從設計的角度來考慮。接口和python其他語法現象一樣，共同構成了python整個語言體系。
接口的意義在於 抽象、不拘細節,從而使同類事物在同一高度具有通用及可替代性。
關於解耦，並不是接口能解耦，而是抽象能解耦 接口只是手段,如果兩個事物有必然聯繫，那麼就不會出現完全解耦，只能耦合轉移。
在系統分析和架構中，分清層次和依賴關係，每個層次不是直接向其上層提供服務（即不是直接實例化在上層中），而是通過定義一組接口，僅向上層暴露其接口功能，上層對於下層僅僅是接口依賴，而不依賴具體類。
- 系統靈活性增強
- 當下層需要改變時，只要接口及接口功能不變，則上層不用做任何修改。甚至可以在不改動上層代碼時將下層整個替換掉，就像我們將一個WD的60G硬盤換成一個希捷的160G的硬盤，計算機其他地方不用做任何改動，而是把原硬盤拔下來、新硬盤插上就行了，因為計算機其他部分不依賴具體硬盤，而只依賴一個IDE接口，只要硬盤實現了這個接口，就可以替換上去。
- 不同部件或層次的開發人員可以並行開工
- 就像造硬盤的不用等造CPU的，也不用等造顯示器的，只要接口一致，設計合理，完全可以並行進行開發，從而提高效率。
那麼具體什麼時候用，什麼時候不用呢？在常見的三層架構中，有以下幾個層次，分別進行說明:
- 界面層
- 也就是展示層，直接呈現給用戶的，可能不同的軟件有不同的呈現方式，比如Web，WinForm,甚至移動APP，在這個層次，我認為是沒有必要寫太多的接口。
- 業務邏輯層
- 這個層次，業務邏輯，可以根據需要使用接口。如果是直接讀寫數據庫什麼的，就直接用調用數據庫訪問層的接口。如果是與多個第三方接口進行交互，那麼就需要接口，不同的渠道各自實現。
- 數據訪問層 數據訪問層，最好使用接口，比如數據庫訪問，這種可以根據不同的數據庫實現相應的接口向業務邏輯層提供服務。
可能在開發的時候，一開始我們並沒有想到要使用接口。可能簡單就用一個類實現了。到後面新的需求過來的時候，發現代碼需要重構，要用接口和抽象類等等。這個也需要看個人編碼的習慣。有的人就長篇大論一個類完成所有的邏輯。這樣的開發人員，應該是很少見過好的代碼，如果見過的話，後面肯定會精簡做到更好。而另外一些人可能一開始就能嗅出來哪些地方需要使用接口，哪些地方使用抽象類，這也是一種思維方式。前面一種只管開發當前的功能。而後面一種則會考慮到以後的擴展。總而言之，需要根據不同的情況進行考慮。
2.1 面向接口編程
面向接口編程：面向接口編程和麵向對象編程並不是平級的，它並不是比面向對象編程更先進的一種獨立的編程思想，而是附屬於面向對象思想體系，屬於其一部分。或者說，它是面向對象編程體系中的思想精髓之一.
2.2 軟件設計中有關接口的原則
我一直認為這個問題，應該從設計的角度來講。在軟件設計的六大設計原則中，與接口直接相關的就有以下兩個：
- 依賴倒置原則 高層模塊不應該依賴底層模塊，二則都應該依賴其抽象，抽象不應該依賴細節；細節應該依賴抽象。
- 問題由來：類A直接依賴類B，假如要將類A改為依賴類C，則必須通過修改類A的代碼來達成。這種場景下，類A一般是高層模塊，負責複雜的業務邏輯；類B和類C是低層模塊，負責基本的原子操作；假如修改類A，會給程序帶來不必要的風險。
- 解決方案：面向接口編程,將類A修改為依賴接口I，類B和類C各自實現接口I，類A通過接口I間接與類B或者類C發生聯繫，則會大大降低修改類A的幾率。
- 接口隔離原則 定義：客戶端不應該依賴它不需要的接口；一個類對另一個類的依賴應該建立在最小的接口上。
- 問題由來：類A通過接口I依賴類B，類C通過接口I依賴類D，如果接口I對於類A和類B來說不是最小接口，則類B和類D必須去實現他們不需要的方法。
- 解決方案：在設計接口的時候要精簡單一,將臃腫的接口I拆分為獨立的幾個接口，類A和類C分別與他們需要的接口建立依賴關係。也就是採用接口隔離原則。
- 總結
- 單一職責原則告訴我們實現類要職責單一；里氏替換原則告訴我們不要破壞繼承體系；依賴倒置原則告訴我們要面向接口編程；接口隔離原則告訴我們在設計接口的時候要精簡單一；迪米特法則告訴我們要降低耦合。而開閉原則是總綱，他告訴我們要對擴展開放，對修改關閉。接口在設計模式中，有很多的靈活應用。
接口、抽象類的區別
閱讀更多 程序猿的內心獨白 的文章
