紙上得來終覺淺，絕知此事要躬行。——陸遊
※引導語
在設計開發過程中往往會出現這麼一現象：在開始設計、開發的時候，一個接口的用來做什麼什麼的設計的很明確，前期開發過程中接口看著也比較惹人喜愛；隨著，開發周期的拉長，尤其是經過幾人手後，你會發現，它再也不是那個接口了，而是變得臃腫，都不想看了。
那怎麼辦呢？
好辦，學好咱們今天講的接口隔離原則，並應用之。
01 接口隔離原則是什麼
定義
接口隔離原則可以定義為：建立單一接口，不要建立臃腫龐大的接口。
也就是說，接口儘量細化，同時接口中的方法儘量少。
看到這，大家可能會不由自主的想到前面講的 單一職責原則，「咔」。這裡大家一定要注意，單一職責原則，強調的是職責，站在業務邏輯的角度；而接口隔離原則，強調接口的方法儘量少。
02 接口隔離原則的好處
符合我們常說的高內聚低耦合的設計思想，從而使得類具有很好的可讀性、可擴展性和可維護性。
03 接口隔離原則規約
在設計接口的時候，我們可以參考以下幾點規約：
接口要儘量小這個也是接口隔離原則定義中的核心點，不出現臃腫的接口（Fat Interface），但是「小」是有限度的，首先就是不能違反單一職責原則，因此，我們在設計接口的時候，也要站在業務角度考慮。
接口要高內聚什麼是高內聚？高內聚就是提高接口、類、模塊的處理能力，減少對外的交互。具體到接口隔離原則就是，要求在接口中儘量少公布public方法，接口是對外的承諾，承諾越少對系統的開發越有利，變更的風險也就越少，同時也有利於降低成本。
說到高內聚，低耦合必然得提一下。
模塊之間存在依賴，關係越緊密， 耦合越強， 模塊獨立性越差。
模塊內部的元素， 關聯性越強， 則內聚越高， 模塊單一性更強。
因此，好多設計都是基於高內聚低耦合這點考慮的。
定製服務一個系統或系統內的模塊之間必然會有耦合，有耦合就要有相互訪問的接口（並不一定就是Java中定義的Interface，也可能是一個類或單純的數據交換），我們設計時就需要為各個訪問者（即客戶端）定製服務，什麼是定製服務？定製服務就是單獨為一個個體提供優良的服務。我們在做系統設計時也需要考慮對系統之間或模塊之間的接口採用定製服務。
採用定製服務就必然有一個要求：只提供訪問者需要的方法，這是什麼意思？
大家可以回想一下自己是怎麼做的，如何寫這個對外接口的。
我舉幾個遇到過的例子：
情況1：原來已經有的（可能給後臺用的返回所有信息的）接口，直接提供。（不建議，尤其大內容耗時查詢）
情況2：有個現成的實現，直接包個接口（Controller）提供出去。（不建議，尤其大內容耗時查詢）
情況3：新寫一個，按需（所需欄位信息）包裝接口對外。（建議）
針對於情況1和2，尤其是在並發量大的時候，很容易導致應用服務的性能下降，嚴重的造成服務宕機。
接口設計是有限度的接口的設計粒度越小，系統越靈活，這是不爭的事實。但是，靈活的同時也帶來了結構的複雜化，開發難度增加，可維護性降低，這不是一個項目或產品所期望看到的，所以接口設計一定要注意適度，這個「度」如何來判斷呢？根據經驗和常識判斷，沒有一個固化或可測量的標準。
04 代碼示例
打電話類圖（結合前面講的UML看此圖）
IConnectionManager：建立連接
IDataTransfer：語音數據轉換
Phone：實現電話功能
關注回復 6，獲取原始碼。
05 總結
您的點讚、在看和關注，是對小編莫大的支持和鼓勵喲！