客戶端不應該依賴它不需要的介面；乙個類對另乙個類的依賴應該建立在最小的介面上
比如 你定義了乙個介面
public inte***ce i
但是a只想實現介面中的method1方法
b只想實現介面中的method2,method3方法
c只想實現介面中的method4,method5方法
如果你這個時候就寫乙個介面,讓a,b,c都去實現i介面的話,這樣會導致a,b,c中會實現不需要的方法,這樣設計介面會導致介面比較臃腫,因此我們要把這個介面分開寫,
介面隔離原則的含義是：建立單一介面，不要建立龐大臃腫的介面，盡量細化介面，介面中的方法盡量少。也就是說，我們要為各個類建立專用的介面，而不要試圖去建立乙個很龐大的介面供所有依賴它的類去呼叫。本文例子中，將乙個龐大的介面變更為3個專用的介面所採用的就是介面隔離原則。在程式設計中，依賴幾個專用的介面要比依賴乙個綜合的介面更靈活。介面是設計時對外部設定的「契約」，通過分散定義多個介面，可以預防外來變更的擴散，提高系統的靈活性和可維護性。
說到這裡，很多人會覺的介面隔離原則跟之前的單一職責原則很相似，其實不然。其一，單一職責原則原注重的是職責；而介面隔離原則注重對介面依賴的隔離。其二，單一職責原則主要是約束類，其次才是介面和方法，它針對的是程式中的實現和細節；而介面隔離原則主要約束介面介面，主要針對抽象，針對程式整體框架的構建。
採用介面隔離原則對介面進行約束時，要注意以下幾點：
介面盡量小，但是要有限度。對介面進行細化可以提高程式設計靈活性是不掙的事實，但是如果過小，則會造成介面數量過多，使設計複雜化。所以一定要適度。
為依賴介面的類定**務，只暴露給呼叫的類它需要的方法，它不需要的方法則隱藏起來。只有專注地為乙個模組提供定**務，才能建立最小的依賴關係。
提高內聚，減少對外互動。使介面用最少的方法去完成最多的事情。
運用介面隔離原則，一定要適度，介面設計的過大或過小都不好。設計介面的時候，只有多花些時間去思考和籌畫，才能準確地實踐這一原則
設計模式之介面隔離原則
基本介紹 客戶端不應該依賴它不需要的介面，即乙個類對另乙個類的依賴應該建立在最小的介面上 應用例項 例1 public class segregation1 inte ce inte ce1 class b implements inte ce1 override public void opera...
設計模式 （介面隔離原則）
介面有兩種型別 建立單一介面，介面盡量要細化，同時介面中的方法盡量少 這回可能會有人問了，這跟單一職責原則不是相同的嗎 單一職責要求的是類和介面職責單一，強調的是職責，業務邏輯上的劃分 介面隔離要求介面的方法盡量少，需要盡量使用多個專門介面 下面舉個例子來說明 車的好壞都是口碑，質量和品牌 好車類 ...
設計模式 介面隔離原則
反例 inte ce inte ce1class b implements inte ce1 override public void operation2 override public void operation3 override public void operation4 overrid...