4.3 保證接口的純潔性 接口隔離原則是對接口進行規范約束，其包含以下4層含義： ● 接口要盡量小 這是接口隔離原則的核心定義，不出現臃腫的接口（Fat Interface），但是“小”是有限度的，首先就是不能違反單一職責原則，什么意思呢？我們在單一職責原則中提到一個IPhone的例子，在這里，我們使用單一職責原則把兩個職責分解到兩個接口中，類圖如圖4-3所示。  圖4-3 電話類圖 仔細分析一下IConnectionManager接口是否還可以再繼續拆分下去，掛電話有兩種方式：一種是正常的電話掛斷，一種是電話異常掛機，比如突然沒電了，通信當然就斷了。這兩種方式的處理應該是不同的，為什么呢？正常掛電話，對方接受到掛機信號，計費系統也就停止計費了，那手機沒電了這種方式就不同了，它是信號丟失了，中繼服務器檢查到了，然后通知計費系統停止計費，否則你的費用不是要瘋狂地增長了嗎？ 思考到這里，我們是不是就要動手把IConnectionManager接口拆封成兩個，一個接口是負責連接，一個接口是負責掛電話？是要這樣做嗎？且慢，讓我們再思考一下，如果拆分了，那就不符合單一職責原則了，因為從業務邏輯上來講，通信的建立和關閉已經是最小的業務單位了，再細分下去就是對業務或是協議（其他業務邏輯）的拆分了。想想看，一個電話要關心3G協議，要考慮中繼服務器，等等，這個電話還怎么設計得出來呢？從業務層次來看，這樣的設計就是一個失敗的設計。一個原則要拆，一個原則又不要拆，那該怎么辦？好辦，根據接口隔離原則拆分接口時，首先必須滿足單一職責原則。 ● 接口要高內聚 什么是高內聚？高內聚就是提高接口、類、模塊的處理能力，減少對外的交互。比如你告訴下屬“到奧巴馬的辦公室偷一個×××文件”，然后聽到下屬用堅定的口吻回答你：“是，保證完成任務！”一個月后，你的下屬還真的把×××文件放到你的辦公桌上了，這種不講任何條件、立刻完成任務的行為就是高內聚的表現。具體到接口隔離原則就是，要求在接口中盡量少公布public方法，接口是對外的承諾，承諾越少對系統的開發越有利，變更的風險也就越少，同時也有利于降低成本。 ● 定制服務 一個系統或系統內的模塊之間必然會有耦合，有耦合就要有相互訪問的接口（并不一定就是Java中定義的Interface，也可能是一個類或單純的數據交換），我們設計時就需要為各個訪問者（即客戶端）定制服務，什么是定制服務？定制服務就是單獨為一個個體提供優良的服務。我們在做系統設計時也需要考慮對系統之間或模塊之間的接口采用定制服務。采用定制服務就必然有一個要求：只提供訪問者需要的方法，這是什么意思？我們舉個例子來說明，比如我們開發了一個圖書管理系統，其中有一個查詢接口，方便管理員查詢圖書，其類圖如圖4-4所示。  圖4-4 圖書查詢類圖 在接口中定義了多個查詢方法，分別可以按照作者、標題、出版社、分類進行查詢，最后還提供了混合查詢方式。程序寫好了，投產上線了，突然有一天發現系統速度非常慢，然后就開始痛苦地分析，最終發現是訪問接口中的complexSearch(Map map)方法并發量太大，導致應用服務器性能下降，然后繼續跟蹤下去發現這些查詢都是從公網上發起的，進一步分析，找到問題：提供給公網（公網項目是另外一個項目組開發的）的查詢接口和提供給系統內管理人員的接口是相同的，都是IBookSearcher接口，但是權限不同，系統管理人員可以通過接口的complexSearch方法查詢到所有的書籍，而公網的這個方法是被限制的，不返回任何值，在設計時通過口頭約束，這個方法是不可被調用的，但是由于公網項目組的疏忽，這個方法還是公布了出去，雖然不能返回結果，但是還是引起了應用服務器的性能巨慢的情況發生，這就是一個臃腫接口引起性能故障的案例。 問題找到了，就需要把這個接口進行重構，將IBookSearcher拆分為兩個接口，分別為兩個模塊提供定制服務，修改后的類圖如圖4-5所示。  圖4-5 修改后的圖書查詢類圖 提供給管理人員的實現類同時實現了ISimpleBookSearcher和IComplexBookSearcher兩個接口，原有程序不用做任何改變，而提供給公網的接口變為ISimpleBookSearcher，只允許進行簡單的查詢，單獨為其定制服務，減少可能引起的風險。 ● 接口設計是有限度的 接口的設計粒度越小，系統越靈活，這是不爭的事實。但是，靈活的同時也帶來了結構的復雜化，開發難度增加，可維護性降低，這不是一個項目或產品所期望看到的，所以接口設計一定要注意適度，這個“度”如何來判斷呢？根據經驗和常識判斷，沒有一個固化或可測量的標準。