按照慣例，首先我們來看一下介面隔離原則的定義。
類間的依賴關係應該建立在最小的介面上。
介面中的方法應該盡量少，不要使介面過於臃腫，不要有很多不相關的邏輯方法。
有點類似於單一職責原則，都是功能盡可能的簡單單一，不要冗餘太多其他不相關的。
單一職責原則主要是類與方法，而介面隔離原則卻是對介面而言的。
小廚洗菜，大廚做飯。
在番茄餐廳的後廚，老闆與求生欲極強的廚師長在聊天。
老闆：最近我們番茄餐廳廣受好評，菜品味道美味，這還得感謝你這位廚師長呀。
廚師長：應該的，這該感謝我。
老闆：嗯？你確定？
廚師長：還沒，還沒說完，這該感謝我…們的郝老板，這次確定了。（冷汗）
老闆：你這求生欲厲害了，嘆為觀止呀。不過現在隨著顧客的增多，人手再次不夠了，再招廚師肯定來不及了，你有什麼好辦法嗎？
廚師長：辦法我還真有乙個，我們可以招點小廚，小廚要好招一些。
老闆：但小廚做飯不夠美味，很容易流失客戶的。
廚師長：小廚不做飯，小廚只負責洗菜。這樣呢，大廚就不用洗菜了，只負責做飯，這樣效率就上去了。
老闆：你是不是不想洗菜？
廚師長：當然不是，我就是，就是，就是替公司著想。
老闆：好吧，準了，招人吧。
之前我們在依賴倒置原則聊過對介面程式設計，所以，首先我們定義乙個廚師介面。
package com.fanqiekt.principle.segregation;
/** * 廚師介面
* * @author 番茄課堂-懶人
*/public inte***ce ichef
接下來，我們寫一下大廚的**，大廚實現了廚師介面。
大廚做飯，但不負責洗菜。
package com.fanqiekt.principle.segregation;
/** * 大廚
* * @author 番茄課堂-懶人
*/public class bigchef implements ichef
@override
public void cooking()
}
小廚不做飯，小廚只洗菜。
package com.fanqiekt.principle.segregation;
/** * 小廚
* * @author 番茄課堂-懶人
*/public class kitchen implements ichef
/*** 做飯的邏輯與小廚無關
*/@override
public void cooking()
}
當然不好，每個類都冗餘了與他不相關的方法。例如，bigchef中的wash方法、kitchen中的cooking方法。
這種現象是怎麼導致的呢？
介面不夠最小化。介面隔離原則就是為了解決這種問題的。
我們可以寫成兩個介面，乙個是做飯的介面，乙個是洗菜的介面。
package com.fanqiekt.principle.segregation;
/** * 做飯介面
* * @author 番茄課堂-懶人
*/public inte***ce icook
package com.fanqiekt.principle.segregation;
/** * 洗菜介面
* * @author 番茄課堂-懶人
*/public inte***ce iwash
我們再來看一下符合介面隔離原則的具體實現類。
package com.fanqiekt.principle.segregation;
/** * 大廚
* * @author 番茄課堂-懶人
*/public class bigchef implements icook
}
package com.fanqiekt.principle.segregation;
/** * 小廚
* * @author 番茄課堂-懶人
*/public class kitchen implements iwash
}
這樣的寫法是不是更加的優雅了。
如果新增一種既洗菜又做飯的廚師型別，那同時實現icook與iwash介面就可以了。
它與單一職責原則類似，優點也是類似的。
降低風險
修改其中的乙個業務，不會影響到業務。
易維護易擴充套件
沒有冗餘**，符合介面隔離原則的介面，會更加容易擴充套件以及維護。
接下來，請您欣賞介面隔離原則的原創歌曲。
嘻哈說：介面隔離原則
作曲：懶人
作詞：懶人
奮鬥了多年總算熬成了大廚才不要關心洗菜
這些瑣事都摘不掉
剛入行一兩年但兢兢業業的小廚還不到烹飪大菜
因為這些來不了
所以介面功能太多在胡鬧
介面功能應該盡可能最少
這就是介面隔離
核心思想就是介面最小
這樣才結構得體
風險降低易擴充套件維護也有格局
用起來它是絕對合理
學習複習新方式，頭戴耳機不小覷。
番茄課堂，學習也要酷。
嘻哈說 設計模式之單一職責原則
首先呢，我們來看一下單一職責原則的定義。就乙個類而言，應該只有乙個引起它變化的原因 這個說法不是很好懂，有一些抽象，不過呢，我們依舊可以嘗試著理解一下。就乙個類而言，只有乙個引起它變化的原因，也就是說，除此之外，不能有其它引起變化的原因。這樣就需要乙個前提，這個類只能負責一項職責，而不能負責其他的職...
設計模式之介面隔離原則
基本介紹 客戶端不應該依賴它不需要的介面，即乙個類對另乙個類的依賴應該建立在最小的介面上 應用例項 例1 public class segregation1 inte ce inte ce1 class b implements inte ce1 override public void opera...
java 設計模式之介面隔離原則
客戶端不應該依賴它不需要的介面 乙個類對另乙個類的依賴應該建立在最小的介面上 比如 你定義了乙個介面 public inte ce i 但是a只想實現介面中的method1方法 b只想實現介面中的method2,method3方法 c只想實現介面中的method4,method5方法 如果你這個時候...