設計圖和原始碼請訪問作者的github：https://github.com/yangsheng20080808/DesignModel

From Now On，Let us begin Design Patterns。

介面隔離原則 Interface Segregation Principle

定義
客戶端不應該依賴它不需要的介面（一個介面中的方法不應該冗餘）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.

我們可以把這兩個定義概括為一句話：建立單一介面，不要建立臃腫龐大的介面。再通俗一點講：介面儘量細化，同時介面中的方法儘量少。

提供給每個模組的都應該是單一介面，提供給幾個模組就應該有幾個介面，而不是建立一個龐大的臃腫的介面，容納所有的客戶端訪問。

介面是我們設計時對外提供的契約，通過分散定義多個介面，可以預防未來變更的擴散，提高系統的靈活性和可維護性。（下一篇文章舉例子具體說明問題）

介面隔離原則是對介面進行規範約束，其包含以下4層含義
介面要儘量小 
這是介面隔離原則的核心定義，不出現臃腫的介面（FatInterface），但是“小”是有限度的，首先就是不能違反單一職責原則。（單一職責原則下一篇文章說）

介面要高內聚 
什麼是高內聚？高內聚就是提高介面、類、模組的處理能力，減少對外的互動。具體到介面隔離原則就是，要求在介面中儘量少公佈public方法，介面是對外的承諾，承諾越少對系統的開發越有利，變更的風險也就越少，同時也有利於降低成本。

定製服務 
一個系統或系統內的模組之間必然會有耦合，有耦合就要有相互訪問的介面，我們設計時就需要為各個訪問者（即客戶端）定製服務，什麼是定製服務？定製服務就是單獨為一個個體提供優良的服務。採用定製服務就必然有一個要求：只提供訪問者需要的方法。

介面設計是有限度的 
介面的設計粒度越小，系統越靈活，這是不爭的事實。但是，靈活的同時也帶來了結構的複雜化，開發難度增加，可維護性降低。

衡量的標準
介面隔離原則是對介面的定義，同時也是對類的定義，介面和類儘量使用原子介面或原子類來組裝。但是，這個原子該怎麼劃分是設計模式中的一大難題，在實踐中可以根據以下幾個規則來衡量：

1. 一個介面只服務於一個子模組或業務邏輯

2. 通過業務邏輯壓縮介面中的public方法，介面時常去回顧，儘量讓介面中的方法簡單緊湊，不要放過多的方法規範，這樣會造成汙染。

3.已經被汙染了的介面，儘量去修改，若變更的風險較大，則採用介面卡模式進行轉化處理

4.瞭解自己的現狀和麵臨的問題，不要盲從。每個專案或產品都有特定的環境因素，別看到大師是這樣做的你就照抄。環境不同，介面拆分的標準就不同。深入瞭解業務邏輯，針對特定場景設計的接口才是最適合的。

寫完這六大原則之後，每一個原則都會舉一個具體的例子對應著來解釋

--------------------- 
作者：yabay2208 
來源：CSDN 
原文：https://blog.csdn.net/yabay2208/article/details/73481127 
版權宣告：本文為博主原創文章，轉載請附上博文連結！