PHP面向?qū)ο笪宕笤瓌t之接口隔離原則的示例分析

這篇文章主要介紹PHP面向?qū)ο笪宕笤瓌t之接口隔離原則的示例分析，文中介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們一定要看完！

具體如下：

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

1.接口隔離

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

ISP的主要觀點(diǎn)如下：

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

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

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

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

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

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

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

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

2.對(duì)接口的污染

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

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

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

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

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

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

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

利用委托分離接口。

利用多繼承分離接口。

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

再來(lái)看一下實(shí)例說(shuō)明

你是否遇到過(guò)非?！芭帧钡慕涌谀?？

舉個(gè)例子來(lái)說(shuō)吧：有一個(gè)跟動(dòng)物有關(guān)的接口，代碼如下：

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

狗是這個(gè)接口的一個(gè)具體實(shí)現(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)建一個(gè)魚(yú)類，它會(huì)游泳，怎么辦呢？我們必須要修改接口，還會(huì)影響到dog類的實(shí)現(xiàn)，而fish也需要實(shí)現(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";
  }
}

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

那么，怎么解決以上問(wèn)題呢？

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

animalCanWalk接口類：

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

AnimalCanSwim接口類：

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

animalCanSpeak接口類：

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

定義好這幾個(gè)接口類之后，dog和fish的實(shí)現(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)的概念：使用多個(gè)專門的接口，而不使用單一的總接口，即客戶端不應(yīng)該依賴那些它不需要的接口。

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

以上是“PHP面向?qū)ο笪宕笤瓌t之接口隔離原則的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對(duì)大家有幫助，更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道！