面向對象設計原則之接口隔離原則

接口隔離原則定義以下：

接口隔離原則(Interface  Segregation Principle, ISP)：使用多個專門的接口，而不使用單一的總接口，即客戶端不該該依賴那些它不須要的接口。

      根據接口隔離原則，當一個接口太大時，咱們須要將它分割成一些更細小的接口，使用該接口的客戶端僅需知道與之相關的方法便可。每個接口應該承擔一種相對獨立的角色，不幹不應乾的事，該乾的事都要幹。這裏的「接口」每每有兩種不一樣的含義：一種是指一個類型所具備的方法特徵的集合，僅僅是一種邏輯上的抽象；另一種是指某種語言具體的「接口」定義，有嚴格的定義和結構，好比Java語言中的interface。對於這兩種不一樣的含義，ISP的表達方式以及含義都有所不一樣：

      (1) 當把「接口」理解成一個類型所提供的全部方法特徵的集合的時候，這就是一種邏輯上的概念，接口的劃分將直接帶來類型的劃分。能夠把接口理解成角色，一個接口只能表明一個角色，每一個角色都有它特定的一個接口，此時，這個原則能夠叫作「角色隔離原則」。

      (2) 若是把「接口」理解成狹義的特定語言的接口，那麼ISP表達的意思是指接口僅僅提供客戶端須要的行爲，客戶端不須要的行爲則隱藏起來，應當爲客戶端提供儘量小的單獨的接口，而不要提供大的總接口。在面向對象編程語言中，實現一個接口就須要實現該接口中定義的全部方法，所以大的總接口使用起來不必定很方便，爲了使接口的職責單一，須要將大接口中的方法根據其職責不一樣分別放在不一樣的小接口中，以確保每一個接口使用起來都較爲方便，並都承擔某一單一角色。接口應該儘可能細化，同時接口中的方法應該儘可能少，每一個接口中只包含一個客戶端（如子模塊或業務邏輯類）所需的方法便可，這種機制也稱爲「定製服務」，即爲不一樣的客戶端提供寬窄不一樣的接口。

      下面經過一個簡單實例來加深對接口隔離原則的理解：

Sunny軟件公司開發人員針對某CRM系統的客戶數據顯示模塊設計瞭如圖1所示接口，其中方法dataRead()用於從文件中讀取數據，方法transformToXML()用於將數據轉換成XML格式，方法createChart()用於建立圖表，方法displayChart()用於顯示圖表，方法createReport()用於建立文字報表，方法displayReport()用於顯示文字報表。 圖1 初始設計方案結構圖       在實際使用過程當中發現該接口很不靈活，例如若是一個具體的數據顯示類無須進行數據轉換（源文件自己就是XML格式），但因爲實現了該接口，將不得不實現其中聲明的transformToXML()方法（至少須要提供一個空實現）；若是須要建立和顯示圖表，除了需實現與圖表相關的方法外，還須要實現建立和顯示文字報表的方法，不然程序編譯時將報錯。       現使用接口隔離原則對其進行重構。

      在圖1中，因爲在接口CustomerDataDisplay中定義了太多方法，即該接口承擔了太多職責，一方面致使該接口的實現類很龐大，在不一樣的實現類中都不得不實現接口中定義的全部方法，靈活性較差，若是出現大量的空方法，將致使系統中產生大量的無用代碼，影響代碼質量；另外一方面因爲客戶端針對大接口編程，將在必定程序上破壞程序的封裝性，客戶端看到了不該該看到的方法，沒有爲客戶端定製接口。所以須要將該接口按照接口隔離原則和單一職責原則進行重構，將其中的一些方法封裝在不一樣的小接口中，確保每個接口使用起來都較爲方便，並都承擔某一單一角色，每一個接口中只包含一個客戶端（如模塊或類）所需的方法便可。

      經過使用接口隔離原則，本實例重構後的結構如圖2所示：

圖2 重構後的結構圖

      在使用接口隔離原則時，咱們須要注意控制接口的粒度，接口不能過小，若是過小會致使系統中接口氾濫，不利於維護；接口也不能太大，太大的接口將違背接口隔離原則，靈活性較差，使用起來很不方便。通常而言，接口中僅包含爲某一類用戶定製的方法便可，不該該強迫客戶依賴於那些它們不用的方法。

擴展 在《敏捷軟件開發——原則、模式與實踐》一書中，RobertC. Martin從解決「接口污染」的角度對接口隔離原則進行了詳細的介紹，你們能夠參閱該書第12章——接口隔離原則(ISP)進行深刻的學習。