設計模式六大設計原則（四）：接口隔離原則

1、定義

有兩種定義：

• Clients should not be forced to depend upon interfaces that they don't use.（客戶端不該該依賴它不須要的接口。）
• The dependency of one class to another one should depend on the smallest possible interface.（類間的依賴關係應該創建在最小的接口上）

注意：這裏的接口不是JAVA意義上的Interface，而是廣義的程序中的無論是Class仍是Interface只要存在依賴，都稱之爲接口。

與單一職責原則相區分，單一職責是根據業務上劃分出的職責的維度進行劃分的，而接口隔離原則是進一步在接口依賴關係關係上進一步劃分，單一職責原則是強調咱們在定義接口時考慮這個接口在整個系統提供的職責單一，而接口隔離原則強調的是根據模塊依賴接口的方法範圍存在不一樣，他們調用該接口須要隔離，如咱們在單一職責原則基礎之上定義接口時若是預期會被多模塊調用了，且多個模塊對依賴該接口的方法範圍存在區別，那麼須要將此接口拆分得再小一點，以複合每一個模塊訪問的接口都是儘可能小的，從而隔離各個模塊。

2、優勢與限制

（一）優勢

• 提升可維護性 由於針對接口的修改只須要關注一個模塊
• 提升設計靈活性 多接口比臃腫接口更靈活

（二）限制

• 過於追求接口隔離，單一職責將接口設計的粒度過小也會使系統結構更爲複雜

3、建議

• 在業務接口中，避免接口被多個模塊調用。這裏和Util類區分，由於util雖然是服務於多個模塊的，可是在設計上，多個模塊對其的訪問範圍並不存在什麼不一樣，因此不必進一步隔離
• 根據業務邏輯壓縮接口中的方法，避免由於一個預期不會改變的業務邏輯屢次調用不一樣的public方法
• 已經被污染了的接口（被多個不一樣的模塊調用），考慮進行修改，如不能考慮使用適配器模式