定義
用戶端不應該依賴它不需要的接口；
一個類對另一個類的依賴應該建立在最小的接口上。
定義解讀
定義包含三層含義：
- 一個類對另一個類的依賴應該建立在最小的接口上；
- 一個接口代表一個角色，不應該将不同的角色都交給一個接口，因為這樣可能會形成一個臃腫的大接口；
- 不應該強迫客戶依賴它們從來不用的方法。
接口隔離原則有點像單一職責原則，但是也有差別，在單一職責原則中，一個接口可能有多個方法，提供給多種不同的調用者所調用，但是它們始終完成同一種功能，是以它們符合單一職責原則，卻不符合接口隔離原則，因為這個接口存在着多種角色，是以可以拆分成更多的子接口，以供不同的調用者所調用。比如說，項目中我們通常有一個Web服務管理的類，接口定義中，我們可能會将所有子產品的資料調用方法都在接口中進行定義，因為它們都完成的是同一種功能：和伺服器進行資料互動；但是對于具體的業務功能子產品來說，其他子產品的資料調用方法它們從來不會使用，是以不符合接口隔離原則。
優點
使用接口隔離原則，意在設計一個短而小的接口和類，符合我們常說的高内聚低耦合的設計思想，進而使得類具有很好的可讀性、可擴充性和可維護性。
問題提出
類A通過接口I依賴類B，類C通過接口I依賴類D，如果接口I對于類A和類C來說不是最小接口，而類B和類D必須去實作它們不需要的方法。下面通過一個UML圖來說明這種現象：
在這裡，我們定義了一個動物活動的接口IAnimal，裡面有4個方法：飛行fly、行走walk、吃eat和工作work，然後分别用人類People和鳥類Bird實作了這個接口。中國人類ChinesePeople和鹦鹉類Parrot通過接口IAnimal分别依賴類People和類Bird。很明顯，對于ChinesePeople來說，fly方法是多餘的，因為人不會飛；對于Parrot類來說，work方法是多餘的，因為鹦鹉不需要工作。接口IAnimal對于類ChinesePeople和類Parrot來說不是最小接口。
解決方案
将臃腫的接口IAnimal拆分為獨立的幾個接口，類ChinesePeople和類Parrot分别與它們需要的接口建立依賴關系，也就是采用接口隔離原則。修改後的UML圖如下所示：
示例
源碼下載下傳(源碼為根據修改的UML圖編寫的)
說明：從UML圖可以看到，遵守接口隔離原則，會使代碼量增加不少，源碼中也是這樣；實際上，IOS在定義協定的時候，可以設定方法為可選實作(@optional)和必須實作(@required，預設值)，我們可以設定work方法和fly方法為可選實作的方法，這樣在類People和類Bird中，這兩個方法可以根據需要來決定是否實作。采用這種方式，功能上實作是沒有問題，對于簡單的接口來說，也便于維護和管理。但是，當方法随着業務需求的增加而不斷增加的話，如果我們不應用接口隔離原則，那麼就可能形成一個龐大臃腫的接口，這樣的接口的可維護性和重用性是很差的。是以，我們應該盡量細化接口，本篇将一個接口變更為3個專用的接口所采用的就是接口隔離原則。在項目開發中，依賴幾個專用的接口要比依賴一個綜合的接口更加靈活。通過分散定義多個接口，可以預防外來變更的擴散，提高系統的靈活性和可維護性。
雖然接口隔離原則很有意義，但在實際項目中，應該注意度的把握，接口設計的過大或過小都不好，應該根據實際情況多思考再進行設計。
傳回目錄
循自然之道，撫浮躁之心