本文實例講述了PHP面向對象五大原則之接口隔離原則(ISP)。分享給大家供大家參考，具體如下：

設計應用程序的時候，如果一個模塊包含多個子模塊，那么我們應該小心對模塊做出抽象。設想該模塊由一個類實現，我們可以把系統抽象成一個接口。但是要添加一個新的模塊擴展程序時，如果要添加的模塊只包含原系統中的一些子模塊，那么系統就會強迫我們實現接口中的所有方法，并且清寒要編寫一些啞方法。這樣的接口被稱為肚胖接口或者被污染的接口，使用這樣的接口將會給系統引入一些不當的行為，這些不當的行為可能導致不正確的結果，也可能導入資源浪費。

1.接口隔離

接口隔離原則（Interface Segregation Principle, ISP）表明客戶端不應該被強迫實現一些他們不會使用的接口，應該把胖接口中的方法分組，然后用多個接口替代它，每個接口服務于一個子模塊。簡單地說，就是使用多個專門的接口比使用單個接口要好很多。

ISP的主要觀點如下：

1）一個類對另外一個類的依賴性應當是建立在最小的接口上的。

ISP可以達到不強迫客戶（接口的使用方法）依賴于他們不用的方法，接口的實現類應該只呈現為單一職責的角色（遵循SRP原則）

ISP還可以降低客戶之間的相互影響---當某個客戶要求提供新的職責（需要變化）而迫使接口發生改變時，影響到其他客戶程序的可能性最小。

2）客戶端程序不應該依賴它不需要的接口方法（功能）。

客戶端程序就應該依賴于它不需要的接口方法（功能），那依賴于什么？依賴它所需要的接口?？蛻舳诵枰裁唇涌诰褪翘峁┦裁唇涌?，把不需要的接口剔除，這就要求對接口進行細化，保證其純潔性。

比如在繼承時，由于子類將繼承父類中的所有可用方法；而父類中的某些方法，在子類中可能并不需要。例如，普通員工和經理都繼承自雇員這個接口，員工需要每天寫工作日志，而經理不需要。因此不能用工作日志來卡經理，也就是經理不應該依賴于提交工作日志這個方法。

可以看出，ISP和SRP在概念上是有一定交叉的。事實上，很多設計模式在概念上都有交叉，甚至你很難判斷一段代碼屬于哪一種設計模式。

ISP強調的是接口對客戶端的承諾越少越好，并且要做到專一。當某個客戶程序的要求發生變化，而迫使接口發生改變時，影響到其他客戶程序的可能性小。這實際上就是接口污染的問題。

2.對接口的污染

過于臃腫的接口設計是對接口的污染。所謂的接口污染就是為接口添加不必要的職責，如果開發人員在接口中增加一個新功能的目的只是減少接口實現類的數目，則此設計將導致接口被不斷地“污染”并“變胖”。

“接口隔離”其實就是定制化服務設計的原則。使用接口的多重繼承實現對不同的接口的組合，從而對外提供組合功能---達到“按需提供服務”。

接口即要拆，但也不能拆得太細，這就得有個標準，這就是高內聚。接口應該具備一些基本的功能，能獨一完成一個基本的任務。

在實際應用中，會遇到如下問題：比如，我需要一個能適配多種類型數據庫的DAO實現，那么首先應實現一個數據庫操作的接口，其中規定一些數據庫操作的基本方法，比如連接數據庫、增刪改查、關閉數據庫等。這是一個最少功能的接口。對于一些MySQL中特有的而其他數據庫里并不存在的或性質不同的方法，如PHP里可能用到的MySQL的pconnect方法，其他數據庫里并不存在和這個方法相同的概念，這個方法也就不應該出現在這個基本的接口里，那這個基本的接口應該有哪些基本的方法呢？PDO已經告訴你了。

PDO是一個抽象的數據庫接口層，它告訴我們一個基本的數據庫操作接口應該實現哪些基本的方法。接口是一個高層次的抽象，所以接口里的方法都應該是通用的、基本的、不易變化的。

還有一個問題，那些特有的方法應該怎么實現？根據ISP原則，這些方法可以在別一個接口中存在，讓這個“異類”同時實現這兩個接口。

對于接口的污染，可以考慮這兩條處理方式：

利用委托分離接口。

利用多繼承分離接口。

委托模式中，有兩個對象參與處理同一個請求，接受請求的對象將請求委托給另一個對象來處理，如策略模式、代理模式等中都應用到了委托的概念。

再來看一下實例說明

你是否遇到過非常“胖”的接口呢？

舉個例子來說吧：有一個跟動物有關的接口，代碼如下：

<?phpinterface Animal{  public function walk();  public function speak();}

狗是這個接口的一個具體實現：

<?phprequire_once "animal.php";class Dog implements Animal{  public function walk(){    echo "dogs can walk";  }  public function speak(){    echo "dogs can speak";  }}

ok，現在我們想創建一個魚類，它會游泳，怎么辦呢？我們必須要修改接口，還會影響到dog類的實現，而fish也需要實現walk和speak方法，如下代碼所示：

Animal接口類：

<?phpinterface Animal{  public function walk();  public function speak();  public function swim();}

dog類：

<?phprequire_once "animal.php";class Dog implements Animal{  public function walk(){    echo "dogs can walk";  }  public function speak(){    echo "dogs can speak";  }  public function swim(){  }}

fish類：

<?phprequire_once "animal.php";class Fish implements Animal{  public function walk(){  }  public function speak(){  }  public function swim(){    echo "fish can swim";  }}

這時Animal接口類就呈現出了”胖“接口的特征了。所謂胖接口其實就是接口中定義了不是所有實現類都需要的方法，就像Animal接口類，有些動物是不會游泳的，有些動物是不會行走的，還有些動物是不會飛的。如果將這些方法都寫在一個Animal接口類中，那么后期的擴展和維護簡直就是一場災難。

那么，怎么解決以上問題呢？

很簡單，接口細化即可，將Animal接口類拆分成三個接口類：

animalCanWalk接口類：

<?phpinterface animalCanSpeak{  public function speak();}

AnimalCanSwim接口類：

<?phpinterface AnimalCanSwim{  public function swim();}

animalCanSpeak接口類：

<?phpinterface animalCanSpeak{  public function speak();}

定義好這幾個接口類之后，dog和fish的實現就容易多了，

<?phprequire_once "animalCanSpeak.php";require_once "animalCanWalk.php";class Dog implements animalCanSpeak,animalCanWalk{  public function walk(){    echo "dogs can walk";  }  public function speak(){    echo "dogs can speak";  }}

<?phprequire_once "animalCanSwim.php";class Fish implements AnimalCanSwim{  public function swim(){    echo "fish can swim";  }}

總結一下：

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

在使用接口隔離原則時，我們需要注意控制接口的粒度，接口不能太小，如果太小會導致系統中接口泛濫，不利于維護；接口也不能太大，太大的接口將違背接口隔離原則，靈活性較差，使用起來很不方便。一般而言，接口中僅包含為某一類用戶定制的方法即可，不應該強迫客戶依賴于那些它們不用的方法。

希望本文所述對大家PHP程序設計有所幫助。