用多個專門的介面，而不使用單一的總介面，客戶端不應該依賴其他介面
乙個類對應乙個類的依賴應該建立在最小的介面上。
建立單一介面，不要建立，龐大臃腫的介面
盡量細化介面，介面中的方法越少，比較好，適度就好
符合我們開發中的高內聚低耦合的特性,在開發的時候考慮到要修改的地方
例如說：動物有的會吃，會飛，會游泳，但是如果把他定義在乙個介面中，例如dog類去實現介面，顯然， 會吃,不會飛，會游泳 這樣的話 會飛這個方法只能為空了，以此類推鳥會吃，會飛，但是大雁會飛，企鵝會游泳 這樣的話 另外兩個方法就廢了：如下
生活中的介面隔離原則
例子：動物 大雁會吃，狗也會吃，大雁會飛 狗不會飛，也就是將會飛的歸為一類，將不會飛的歸為一類
**中的隔離原則：
建立三個介面 飛丶吃丶游泳
public
inte***ce
eatanimalaction
public
inte***ce
flyanimalaction
public
inte***ce
swimanimalaction
小鳥：
public
class
bird
implements
eatanimalaction
,flyanimalaction
@override
public
void
fly(
)}
大家看到這個就明白了吧，細粒度的可以進行組裝的，粗粒度的沒辦法進行拆分，設計的時候適度，多花時間進行設計
設計模式五大原則
1 單一職責 不論是在設計類，介面還是方法，單一職責都會處處體現，單一職責的定義 我們把職責定義為系統變化的原因。所有在定 義類，介面，方法的時候。定義完以後再去想一想是不能多於乙個的動機去改變這個類，介面，方法。如果答案是肯定的，說明定義的類，介面，方法則多於乙個職 責。故違背單一職責，遇到這種情...
設計模式五大原則
1 單一職責原則 不論是在設計類，介面還是方法，單一職責都會處處體現，單一職責的定義 我們把職責定義為系統變化的原因。所有在定義類，介面，方法的時候。定義完以後再去想一想是不能多於乙個的動機去改變這個類，介面，方法。如果答案是肯定的，說明定義的類，介面，方法則多於乙個職 責。故違背單一職責，遇到這種...
設計模式的五大原則 五
乙個物件對其他物件最少的了解，又叫做最少知道的原則 盡量降低，類與類之間的耦合，類之間的弱耦合，如果大量使用迪公尺特法則 生活中的迪公尺特原則 例如 boos 讓部門經理我要你們部門的人的所有材料，顯然boos不會親自幹這個事了，boos通知部門經理，部門經理在通知工作人員你們把材料交到我的手中，經...