面向物件的五大設計原則之介面隔離原則
通過上篇文章，我們已經對於五大設計原則的單一職責原則有了一定的瞭解，接下來我們就來看下第二種設計原則，介面隔離原則，廢話不多說啊，來仔細看。
我們在設計程式的時候，如果一個模組包含多個子模組，那麼我們應該小心的對該模組做出抽象，假設該模組由一個類來實現，我們就可以把系統抽象成一個介面，但是要新增一個新的模組擴充套件程式的時候，並且這個新的模組擴充套件程式只包含部分子模組，那麼系統會強迫我們在新的擴充套件程式中實現所有的方法，並且還要編寫一些啞方法，這種介面，我們成為胖介面或者被汙染的介面，我們使用這樣的介面，會給系統引入一些不當的行為，可能會導致錯誤的結果或者說導致資源浪費。
要避免上述的問題呢，很簡單，就是使用介面隔離原則（interface segregation principle，簡稱ISP），這個原則的意思就是，客戶端不應該被強迫實現一些它們不會使用的介面，並且應該把胖介面中的方法分組，使用多個介面來替代它，每個介面服務於一個子模組。簡單來說呢，就是使用多個專門的介面，比使用單個介面來處理所有的事物要好的多得多。
我們來看下介面隔離原則中的一些內容：
1、一個類對另外一個類的依賴性應該建立在最小的介面上
介面隔離原則可以做到不強迫客戶（介面的使用方）依賴於它們不會使用的方法，介面的實現類應該只是呈現為單一職責的角色。介面隔離原則還可以客戶之間的相互影響，也就是說，當某個客戶要求提供新的職責（需求變化），迫使介面發生變化時，影響到其他使用者的可能性會降低到最小。
2、客戶端程式不應該依賴它不需要的介面方法（功能）
客戶端程式只需要依賴它本身所需要的介面，別的都不需要依賴，也就是說，客戶端需要什麼，我們就提供什麼，把不需要的剔除，這就要求切口進行細化，保證其本身的純潔性。
你比如我們在應用繼承的時候，由於子類將會繼承父類中所有可用的方法，然而父類中的某些方法，子類可能並不需要，舉個栗子啊，比如普通員工和經理都是繼承僱員這個介面，員工需要每天寫工作日誌，但是經理不需要，一次我們不能用工作日誌來卡經理，也就是說經理不應該依賴提交工作日誌這個方法。
我們可以感覺出來哈，這個介面隔離原則和單一職責原則，在概念方面有一定程度上的交叉，實際上，很多設計模式在概念上都有交叉，甚至於我們很難分辨出某一段程式碼究竟是屬於哪個設計模式。
不過，介面隔離原則，強調的是介面對於客戶端的承諾越少越好，並且要做到專一，當某個客戶程式的要求出現變化，而迫使介面發生變化時，影響其他客戶程式的可能性越小越好，實際上就是介面汙染的問題。
過於臃腫的介面設計就是對介面的汙染，所謂的介面汙染就是指為介面添加了不必要的職責，如果開發人員在介面中新增一個功能的目的只是減少介面實現類的數目，那麼這個介面設計就會導致介面不斷地被汙染並且發胖。
這個介面汙染會給系統帶來維護困難和重用性差等方面的問題，為了能夠重用被汙染的介面，介面的實現類就被迫要實現和維護不需要的功能方法。
而介面隔離原則就是定製化服務設計的原則，我們使用介面的多重繼承來實現對不同介面的組合，從而對外提供組合功能，最終達到按照需求提供服務的目的。
來看張圖片：
按著上圖來分析的話，客戶A需要A服務，但是隻要針對客戶A的方法發生變化，客戶B、C就會受到影響，所以呢，我們這種設計就需要對介面進行隔離。
再來看隔離後的圖片：
再來按著上述圖片進行分析， 如果針對客戶A的方法發生變化，那麼客戶B、C就不會受到影響，到這裡大家可能會有疑問，按著上述思想來進行介面的拆分的話，那我們需要做的介面豈不是很多，這個就需要我們有個標準了，也可以叫做高內聚，也就是說，介面要拆，但是不能拆得太細，最終的介面，應該具備一些基本的功能，能獨立完成一項基本的任務。
上述兩張圖片也只是一個抽象的例子，我們在實際的應用中，還是會遇到一些問題的，比如，我們需要一個能適配多種型別資料庫的DAO實現，那麼我們首先應該是實現一個數據庫操作的介面，在其中規定一些資料庫操作的基本方法，像連線資料庫，增刪改查操作方法，關閉資料庫連線等，這是一個最少功能的介面，對於一些MySQL中特有的而其他資料庫不具有的或者性質不同的方法，如PHP中可能用的MySQL的pconnect方法，其他資料庫裡並不存在和這個方法相同的概念，這個方法就不應該出現在基本的接口裡，那麼基本的方法應該有哪些呢？答案就在PDO中。
PDO是一個抽象的資料介面層，它告訴我們一個基本的資料庫操作介面應該實現哪些基本的方法，介面是一個高層次的抽象，所以接口裡的方法應該是通用的、基本的、不易變化的，還有就是那些特有的方法我們可以根據介面隔離原則，我們可以設計另外一個介面，讓這個含有特殊方法的類，同時實現這兩個介面就好了。
對於介面汙染我們可以有如下兩種處理方案：
- 利用委託分離介面
- 利用多繼承分離介面
在委託模式中，有兩個物件參與處理同一個請求，接受請求的物件會將請求委託給裡一個物件來處理，像策略模式、代理模式等都應用到了委託的概念。
好啦，本次記錄就到這裡了。
如果感覺不錯的話，請多多點贊支援哦。。。