PHP のオブジェクト指向 5 原則とインターフェース分離の原則の詳細な説明

この記事の例では、PHP の 5 つのオブジェクト指向原則のうちのインターフェイス分離原則 (ISP) について説明します。参考のために皆さんと共有してください。詳細は次のとおりです: <br>

アプリケーションを設計するとき、モジュールに複数のサブモジュールが含まれている場合、モジュールを抽象化するように注意する必要があります。モジュールがクラスによって実装されていると仮定すると、システムをインターフェイスに抽象化できます。しかし、新しいモジュール拡張プログラムを追加するときに、追加するモジュールに元のシステムのいくつかのサブモジュールしか含まれていない場合、システムはインターフェイスにすべてのメソッドを実装することを強制するため、いくつかのダムメソッドを記述する必要があります。このようなインターフェイスは、ファット インターフェイスまたは汚染されたインターフェイスと呼ばれます。このようなインターフェイスを使用すると、システムに不適切な動作が導入され、誤った結果が生じる可能性があり、リソースの無駄遣いにつながる可能性があります。

1. インターフェイス分離

インターフェイス分離原則 (ISP) は、クライアントが使用しないインターフェイスの実装を強制されるべきではなく、ファット インターフェイス内のメソッドをグループ化し、各インターフェイスが機能する複数のインターフェイスに置き換える必要があることを示しています。サブモジュール。簡単に言えば、単一のインターフェイスよりも複数の特殊なインターフェイスを使用する方がはるかに優れています。

ISP の主なポイントは次のとおりです:

1) あるクラスの別のクラスへの依存関係は、最小のインターフェイスに基づく必要があります。

ISP は、顧客 (インターフェースの使用方法) が使用しないメソッドに依存することを強制しないという目標を達成できます。インターフェースの実装クラスは (SRP 原則に従って) 単一責任の役割のみを提示する必要があります。顧客間の相互影響を減らす --- 顧客が新たな責任を要求し（変更が必要）、インターフェースの変更を余儀なくされた場合、他の顧客プログラムに影響を与える可能性は最小限に抑えられます。

2) クライアント プログラムは、必要のないインターフェイス メソッド (関数) に依存すべきではありません。

クライアント プログラムは、必要のないインターフェイス メソッド (関数) に依存する必要がありますが、何に依存しますか?必要なインターフェイスによって異なります。クライアントが必要とするあらゆるインターフェイスを提供し、不要なインターフェイスを削除してインターフェイスの純度を確保する必要があります。

たとえば、継承する場合、サブクラスは親クラスで使用可能なすべてのメソッドを継承しますが、親クラスの一部のメソッドはサブクラスでは必要ない場合があります。たとえば、一般の従業員とマネージャーはどちらも従業員インターフェイスを継承します。従業員は毎日作業ログを作成する必要がありますが、マネージャーはその必要がありません。したがって、作業ログを使用して管理者をブロックすることはできません。つまり、管理者は作業ログを提出する方法に依存すべきではありません。

ISP と SRP には概念上いくつかの重複があることがわかります。実際、多くの設計パターンは概念的に重複しており、コードの一部がどの設計パターンに属しているかを判断することさえ困難です。

ISP は、インターフェイスがクライアントに対してできる限りの約束を持たず、具体的である必要があることを強調します。あるクライアントプログラムの要件が変更され、インターフェースが強制的に変更された場合でも、他のクライアントプログラムに影響を与える可能性は低いです。これは実際には界面汚染の問題です。

2. インターフェースの汚染

過度に肥大化したインターフェースのデザインはインターフェースの汚染です。いわゆるインターフェイス汚染とは、開発者がインターフェイス実装クラスの数を減らすためだけに新しい機能をインターフェイスに追加すると、インターフェイスが継続的に「汚染」され、「肥大化」することになります。 「。」

「インターフェースの分離」は、実際にはカスタマイズされたサービス設計の原則です。インターフェースの多重継承を使用して、異なるインターフェースを組み合わせて外部結合機能を提供し、「サービス・オン・デマンド」を実現します。

インターフェースは分解する必要がありますが、あまり細かく分解することはできません。統一性の高い基準が必要です。インターフェイスにはいくつかの基本的な機能があり、基本的なタスクを独自に完了できる必要があります。

実際のアプリケーションでは、次の問題に遭遇するでしょう: たとえば、複数のタイプのデータベースに適応できる DAO 実装が必要な場合、最初にデータベース操作のいくつかの基本的な方法を規定するデータベース操作インターフェースを実装する必要があります。データベースへの接続、データベースの追加、削除、変更、確認、クローズなど。これは最小限の機能を備えたインターフェイスです。 MySQL に固有だが他のデータベースには存在しない、または性質が異なる一部のメソッド (PHP で使用できる MySQL の pconnect メソッドなど) については、他のデータベースにはこのメソッドと同じ概念がないため、このメソッドは使用できません。この基本インターフェイスにはどのような基本メソッドが必要ですか? PDO はそう言いました。

PDO は抽象データベース インターフェイス層であり、基本的なデータベース操作インターフェイスがどのような基本メソッドを実装する必要があるかを示します。インターフェイスは高レベルの抽象化であるため、インターフェイス内のメソッドは普遍的で基本的であり、簡単に変更できないものである必要があります。

別の質問があります。これらの独自のメソッドをどのように実装する必要があるのでしょうか? ISP の原則によれば、これらのメソッドは別のインターフェイスに存在でき、この「異種」が両方のインターフェイスを同時に実装できるようになります。

インターフェイスの汚染については、次の 2 つの処理方法を検討できます:

インターフェイスを分離するために委任を使用します。

多重継承を使用してインターフェースを分離します。

委任モードでは、2 つのオブジェクトが同じリクエストの処理に参加し、リクエストを受け入れたオブジェクトがリクエストを別のオブジェクトに委任して処理します。委任の概念は、ストラテジ モード、プロキシ モードなどに適用されます。

例を見てみましょう

非常に「太い」インターフェースに遭遇したことがありますか?

例を見てみましょう: 動物に関連したインターフェイスがあり、コードは次のとおりです:

<br>

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

Dog はこのインターフェイスの特定の実装です:

<br/>

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

さて、次のことを行います。魚は泳げるのですが、どうすればよいでしょうか?インターフェースを変更する必要があります。これは犬クラスの実装にも影響します。また、次のコードに示すように、魚は walk メソッドと speech メソッドを実装する必要があります。

Animal インターフェース クラス:

<br/>

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

Dog クラス:

<br/>

1. <?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 クラス:

<br/>

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

この時点で、Animal インターフェース クラスは「ファット」インターフェースの特性を示しています。いわゆるファット インターフェイスとは、実際には、Animal インターフェイス クラスと同様に、一部の動物は泳げない、一部の動物は歩けない、一部の動物は飛べないというメソッドをインターフェイスが定義していることを意味します。これらのメソッドが Animal インターフェイス クラスで記述されている場合、後の拡張とメンテナンスが大変なことになります。

では、上記の問題を解決するにはどうすればよいでしょうか?

これは非常に簡単です。インターフェースを改良し、Animal インターフェース クラスを 3 つのインターフェース クラスに分割するだけです。

animalCanWalk接口类：

<br/>

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

AnimalCanSwim接口类：

<br/>

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

animalCanSpeak接口类：

<br/>

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

定义好这几个接口类之后，dog和fish的实现就容易多了，

<br/>

1. <?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";
     }
   }

<br>

接口隔离原则(Interface Segregation Principle, ISP)的概念：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。

在使用接口隔离原则时，我们需要注意控制接口的粒度，接口不能太小，如果太小会导致系统中接口泛滥，不利于维护；接口也不能太大，太大的接口将违背接口隔离原则，灵活性较差，使用起来很不方便。一般而言，接口中仅包含为某一类用户定制的方法即可，不应该强迫客户依赖于那些它们不用的方法。

以上がPHP のオブジェクト指向 5 原則とインターフェース分離の原則の詳細な説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。