java中的介面隔離（ISP）

一個類對另一個類的依賴應該表現成依賴儘可能小的介面。

這個原則是用來處理胖介面的缺陷，避免介面承擔太多的責任。比如說一個介面內的方法可以被分成好幾組，分別為不同的客戶程式服務，說明這個介面太胖了。當然，確實也有一些類不需要內聚的介面，但這些類不應該做為單獨的類被客戶程式直接看到，而應該通過抽象基類或介面來關聯訪問。

介面汙染
所謂介面汙染就是為介面添加了不必要的職責。在介面中加一個新方法只是為了給實作類別帶來好處，以減少類的數目。持續這樣做，介面就被不斷汙染，變胖。實際上，類的數目根本不是什麼問題，介面汙染會帶來維護和重用方面的問題。最常見的問題是我們為了重用被汙染的介面，被迫實現並維護不必要的方法。

分離客戶程式就是分離介面。如果客戶程式是分離的，那麼相應的介面也應該是分離的，因為客戶程式對它們使用的介面有反作用力。通常介面發生了變化，我們就要考慮所有使用介面的客戶程式該如何變化以適應介面的變化。如果客戶程式發生了變化呢？這時也要考慮介面是否需要發生變化，這就是反作用力。有時商務規則的變化不是那麼直接的，而是通過客戶程式的變化引發的，這時我們就需要改變介面以滿足客戶程式的需要。

分離介面的方式一般分為兩種，委託和多繼承。前者把請求委託給別的介面的實作類別來完成需要的職責，後者則是通過實現多個介面來完成需要的職責。兩種方式各有優缺點，通常我們應該先考慮後一個方案，如果涉及到類型轉換時則選擇前一個方案。

胖介面會導致客戶程式之間產生不必要的耦合關係，牽一髮而動全身。分解胖介面，使客戶程式只依賴它需要的方法，從設計上講，簡單易維護，重用度也高。

 

再看看下面的一篇文章

概要Clients should not be forced to depend upon interfaces that they do not use.
不能強迫使用者去依賴那些他們不使用的介面。換句話說，使用多個專門的介面比使用單一的總介面總要好。
它包含了2層意思：
- 介面的設計原則：介面的設計應該遵循最小介面原則，不要把使用者不使用的方法塞進同一個介面裡。
如果一個介面的方法沒有被使用到，則說明該介面過胖，應該將其分割成幾個功能專一的介面。
- 介面的依賴（繼承）原則：如果一個介面a依賴（繼承）另一個介面b，則介面a相當於繼承了介面b的方法，那麼繼承了介面b後的介面a也應該遵循上述原則：不應該包含使用者不使用的方法。
反之，則說明介面a被b給汙染了，應該重新設計它們的關係。

如果使用者被迫依賴他們不使用的介面，當介面發生改變時，他們也不得不跟著改變。換而言之，一個使用者依賴了未使用但被其他使用者使用的介面，當其他使用者修改該介面時，依賴該介面的所有使用者都將受到影響。這顯然違反了開閉原則，也不是我們所期望的。

下面我們舉例說明怎麼設計介面或類之間的關係，使其不違反ISP原則。
假如有一個Door，有lock，unlock功能，另外，可以在Door上安裝一個Alarm而使其具有警示功能。使用者可以選擇一般的Door，也可以選擇具有警示功能的Door。

有以下幾種設計方法：

ISP原則的違反例：

方法一：
在Door介面裡定義所有的方法。圖：

但這樣一來，依賴Door介面的CommonDoor卻不得不實現未使用的alarm()方法。違反了ISP原則。

方法二：
在Alarm介面定義alarm方法，在Door介面定義lock，unlock方法，Door介面繼承Alarm介面。

跟方法一一樣，依賴Door介面的CommonDoor卻不得不實現未使用的alarm()方法。違反了ISP原則。

遵循ISP原則的例：

方法三：通過多重繼承實現

在Alarm介面定義alarm方法，在Door介面定義lock，unlock方法。介面之間無繼承關係。CommonDoor實現Door介面，
AlarmDoor有2種實現方案：
1），同時實現Door和Alarm介面。
2），繼承CommonDoor，並實現Alarm介面。該方案是繼承方式的Adapter設計模式的實現。
第2）種方案更具有實用性。
這種設計遵循了ISP設計原則。

方法四：通過委讓實現

這種方法其實是委讓方式的Adapter設計模式的實現。
在這種方法裡，AlarmDoor實現了Alarm介面，同時把功能lock和unlock委讓給CommonDoor對象完成。
這種設計遵循了ISP設計原則。

小結Interface Segregation Principle (ISP)從對介面的使用上為我們對介面抽象的顆粒度建立了判斷基準：在為系統設計介面的時候，使用多個專門的介面代替單一的胖介面