6大設計原則之4--接口隔離原則

接口分爲兩種：實例接口（Object Interface）和類接口（Class Interface）

隔離也有兩種定義

•     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. （類間的依賴關係應該創建在最小的接口上。）

咱們能夠把這兩個定義歸納爲一句話：創建單一接口，不要創建臃腫龐大的接口。再通 俗一點講：接口儘可能細化，同時接口中的方法儘可能少。看到這裏你們有可能要疑惑了，這與 單一職責原則不是相同的嗎？錯，接口隔離原則與單一職責的審視角度是不相同的，單一職 責要求的是類和接口職責單一，注重的是職責，這是業務邏輯上的劃分，而接口隔離原則要 求接口的方法儘可能少。例如一個接口的職責可能包含10個方法，這10個方法都放在一個接口 中，而且提供給多個模塊訪問，各個模塊按照規定的權限來訪問，在系統外經過文檔約 束「不使用的方法不要訪問」，按照單一職責原則是容許的，按照接口隔離原則是不容許的， 由於它要求「儘可能使用多個專門的接口」。專門的接口指什麼？就是指提供給每一個模塊的都應 該是單一接口，提供給幾個模塊就應該有幾個接口，而不是創建一個龐大的臃腫的接口，容 納全部的客戶端訪問。

接口隔離原則是對接口進行規範約束，其包含如下4層含義： 

• 接口要儘可能小：這是接口隔離原則的核心定義，不出現臃腫的接口（Fat Interface），可是「小」是有限度 的，首先就是不能違反單一職責原則

• 接口要高內聚：什麼是高內聚？高內聚就是提升接口、類、模塊的處理能力，減小對外的交互。具體到接口隔離原則就是，要求在接口中儘可能 少公佈public方法，接口是對外的承諾，承諾越少對系統的開發越有利，變動的風險也就越 少，同時也有利於下降成本。

• 定製服務：一個系統或系統內的模塊之間必然會有耦合，有耦合就要有相互訪問的接口（並不必定 就是Java中定義的Interface，也多是一個類或單純的數據交換），咱們設計時就須要爲各 個訪問者（即客戶端）定製服務，什麼是定製服務？定製服務就是單獨爲一個個體提供優良 的服務。咱們在作系統設計時也須要考慮對系統之間或模塊之間的接口採用定製服務。採用 定製服務就必然有一個要求：只提供訪問者須要的方法，

• 接口設計是有限度的：接口的設計粒度越小，系統越靈活，這是不爭的事實。可是，靈活的同時也帶來告終構 的複雜化，開發難度增長，可維護性下降，這不是一個項目或產品所指望看到的，因此接口 設計必定要注意適度，這個「度」如何來判斷呢？根據經驗和常識判斷，沒有一個固化或可測 量的標準。

最佳實踐

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

• 一個接口只服務於一個子模塊或業務邏輯；

• 經過業務邏輯壓縮接口中的public方法，接口時常去回顧，儘可能讓接口達到「滿身筋骨 肉」，而不是「肥嘟嘟」的一大堆方法；

• 已經被污染了的接口，儘可能去修改，若變動的風險較大，則採用適配器模式進行轉化 處理；

• 瞭解環境，拒絕盲從。每一個項目或產品都有特定的環境因素，別看到大師是這樣作的 你就照抄。千萬別，環境不一樣，接口拆分的標準就不一樣。深刻了解業務邏輯，最好的接口設 計就出自你的手中！