（四） 接口隔離原則
1. 概念：這裡的接口包含兩類，執行個體接口（class）和類接口（Interface），通俗一點将即是建立單一接口，不要建立臃腫龐大的接口，更通俗點就是接口盡量的細化，同時接口中的方法盡量少。
（1）用戶端不應該依賴于它不需要的接口
（2）類間的依賴關系應該建立在最小的接口上
與單一職責原則的區分在于，單一職責需要要求類和接口的職責單一，注重的是職責，這是業務邏輯的劃分，而接口隔離原則要求接口中的方法盡量少。如一個接口的職責可能包含10個方法，這10個方法都放在一個接口中，并且供給多個子產品兒通路，各個子產品兒按照規定的權限來通路，在系統外通過文檔限制“不使用方法不要通路”，按照單一職責原則是允許的，按照接口隔離原則是不允許的，因為它要求盡量使用“多個專門的接口”，提供給幾個子產品兒就應該有幾個接口，而不是建立一個龐大臃腫的接口，容納所有用戶端的通路。
2. 示例：以一個星探查找美女的類圖4-1實作（該關聯是否為聚合，有待商榷，書本上是聚合，本人覺得用依賴關系更為合适）來說明，IPrettyGirl接口代表了一個美女的标準，好的面容，好的身材，好的氣質，星探就根據這些标準來發現美女，圖4-1的類圖是否合理？“情人眼裡出西施”是以，每個時代不論個人還是大衆的審美标準都在改變，比如唐代以胖為美，則好的身材這個美女标準可能就會有變化，再比如，有的沒有GoodLooking，沒有niceFigure，但是屬于氣質美女，所有，星探并不能随着大衆的審美标準而與時俱進，則是因為該星探的抽象類，依賴于一個“龐大”（雖然隻有三個方法）的接口，該接口容納了一些可變的原則，星探應該依賴于具有某些特質的女孩子，是以有了圖4-2中的類圖結構，則此時星探可以尋找到氣質美女，也能尋找到傳統意義的美女。
圖4-1
圖4-2
3.示例引申：在單一職責的原則中如類圖1-4中，IConnectManager是否可以繼續進行拆分下去？挂電話有兩種，一種為正常的電話挂斷，一種為異常挂機，比如突然沒電了，這兩種方式的挂機處理應該是不同的，第一種對方收到挂機信号，計費系統停止計費，而第二種，是信号丢失，中繼伺服器檢查到了，然後通知計費系統停止計費，這樣考慮，是不是得把IConnectManager拆成兩個？，一個負責連接配接，一個負責挂機？如果拆分了則不符合單一職責原則了，因為通信的建立和關閉已經是最小的業務單元了，再細分就是對業務或協定的拆分了，想想一個電話還得關心3G協定和中繼伺服器，則電話不能設計出來了。是以，根據接口隔離原則拆分接口時必須首先滿足單一職責原則。
- 接口盡量小
- 接口高内聚，即盡量在接口中少公布public方法，接口是對外的承諾，承諾越少對系統開發越有利。
- 定制服務，單獨為一個個體提供優良的服務。
- 接口設計是有限度的
圖1-4
4.最佳實踐：；
- 一個接口隻服務于一個子子產品兒和業務邏輯
- 通過業務邏輯壓縮接口中的public方法
- 已經被污染了的接口，盡量去修改，若變更風險大，則用擴充卡模式去轉化
- 了解環境，拒絕忙錯