本文實例講述了PHP面向?qū)ο笪宕笤瓌t之接口隔離原則(ISP)。分享給大家供大家參考，具體如下：

設(shè)計應(yīng)用程序的時候，如果一個模塊包含多個子模塊，那么我們應(yīng)該小心對模塊做出抽象。設(shè)想該模塊由一個類實現(xiàn)，我們可以把系統(tǒng)抽象成一個接口。但是要添加一個新的模塊擴(kuò)展程序時，如果要添加的模塊只包含原系統(tǒng)中的一些子模塊，那么系統(tǒng)就會強(qiáng)迫我們實現(xiàn)接口中的所有方法，并且清寒要編寫一些啞方法。這樣的接口被稱為肚胖接口或者被污染的接口，使用這樣的接口將會給系統(tǒng)引入一些不當(dāng)?shù)男袨椋@些不當(dāng)?shù)男袨榭赡軐?dǎo)致不正確的結(jié)果，也可能導(dǎo)入資源浪費。

1.接口隔離

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

ISP的主要觀點如下：

1）一個類對另外一個類的依賴性應(yīng)當(dāng)是建立在最小的接口上的。

ISP可以達(dá)到不強(qiáng)迫客戶（接口的使用方法）依賴于他們不用的方法，接口的實現(xiàn)類應(yīng)該只呈現(xiàn)為單一職責(zé)的角色（遵循SRP原則）

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

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

客戶端程序就應(yīng)該依賴于它不需要的接口方法（功能），那依賴于什么？依賴它所需要的接口。客戶端需要什么接口就是提供什么接口，把不需要的接口剔除，這就要求對接口進(jìn)行細(xì)化，保證其純潔性。

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

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

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

2.對接口的污染

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

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

接口即要拆，但也不能拆得太細(xì)，這就得有個標(biāo)準(zhǔn)，這就是高內(nèi)聚。接口應(yīng)該具備一些基本的功能，能獨一完成一個基本的任務(wù)。

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

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

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

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

利用委托分離接口。

利用多繼承分離接口。

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

再來看一下實例說明

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

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

?php
interface Animal{
  public function walk();
  public function speak();
}

狗是這個接口的一個具體實現(xiàn)：

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

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

Animal接口類：

?php
interface Animal{
  public function walk();
  public function speak();
  public function swim();
}

dog類：

?php
require_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類：

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

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

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

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

animalCanWalk接口類：

?php
interface animalCanSpeak{
  public function speak();
}

AnimalCanSwim接口類：

?php
interface AnimalCanSwim{
  public function swim();
}

animalCanSpeak接口類：

?php
interface animalCanSpeak{
  public function speak();
}

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

?php
require_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";
  }
}

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

總結(jié)一下：

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

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

更多關(guān)于PHP相關(guān)內(nèi)容感興趣的讀者可查看本站專題：《php面向?qū)ο蟪绦蛟O(shè)計入門教程》、《PHP數(shù)組(Array)操作技巧大全》、《PHP基本語法入門教程》、《PHP運算與運算符用法總結(jié)》、《php字符串(string)用法總結(jié)》、《php+mysql數(shù)據(jù)庫操作入門教程》及《php常見數(shù)據(jù)庫操作技巧匯總》

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