PHP インターフェース分離原則 (ISP) のユースケース分析

今回は、PHP Interface Isolation Principle (ISP) の使用例の分析をお届けします。PHP Interface Isolation Principle (ISP) を使用する際の注意点は何ですか? 以下は実際の事例です。

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

1. インターフェース分離原則 (ISP) は、クライアントが使用しないいくつかのインターフェースを強制的に実装すべきではなく、複数のインターフェースを使用する必要があることを示します。インターフェイス。それぞれがサブモジュールとして機能します。簡単に言えば、単一のインターフェイスよりも複数の特殊なインターフェイスを使用する方がはるかに優れています。

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

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

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

たとえば、継承する場合、サブクラスは親クラスで使用可能なすべてのメソッドを継承しますが、親クラスの一部のメソッドはサブクラスでは必要ない場合があります。たとえば、一般の従業員とマネージャーはどちらも従業員インターフェイスを継承します。従業員は毎日作業ログを作成する必要がありますが、マネージャーはその必要がありません。したがって、作業ログを使用して管理者をブロックすることはできません。つまり、管理者は作業ログを提出する方法に依存すべきではありません。 ISP と SRP には概念上いくつかの重複があることがわかります。実際、多くの設計パターンは概念的に重複しており、コードの一部がどの設計パターンに属しているかを判断することさえ困難です。

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

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

過度に肥大化したインターフェースのデザインはインターフェースの汚染です。いわゆるインターフェイス汚染とは、開発者がインターフェイス実装クラスの数を減らすためだけに新しい機能をインターフェイスに追加すると、インターフェイスが継続的に「汚染」され、「肥大化」することになります。 「。」 「インターフェースの分離」は、実際にはカスタマイズされたサービス設計の原則です。インターフェースの多重継承を使用して、異なるインターフェースを組み合わせて外部結合機能を提供し、「サービス・オン・デマンド」を実現します。 インターフェースは分解する必要がありますが、あまり細かく分解することはできません。統一性の高い基準が必要です。インターフェイスにはいくつかの基本的な機能があり、基本的なタスクを独自に完了できる必要があります。

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

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

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

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

委任を使用してインターフェースを分離します。

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

委任モードでは、2 つのオブジェクトが同じリクエストの処理に参加します。委任の概念は、ストラテジー モード、エージェンシー モードなどに適用されます。

例を見てみましょう

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

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

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

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

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

OK、今度は魚を作成します。魚は泳ぐことができます。どうすればいいですか？インターフェースを変更する必要があります。これは犬クラスの実装にも影響します。また、次のコードに示すように、魚は walk メソッドと speech メソッドを実装する必要があります。

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

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

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

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

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

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

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

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

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

これらをインターフェース クラスの後に定義します。 、犬と魚の実装ははるかに簡単です

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

要約すると:

インターフェイス分離原則 (ISP) の概念: 単一の全体的なインターフェイスを使用するのではなく、複数の特殊なインターフェイスを使用します。つまり、クライアントは次のようにします。必要のないインターフェイスには依存しません。

インターフェイス分離の原則を使用する場合、インターフェイスの粒度を制御することに注意する必要があります。小さすぎると、システム内のインターフェイスが急増します。インターフェイスが大きすぎると、柔軟性が低下し、使用が非常に不便になります。一般に、インターフェイスには特定のタイプのユーザー向けにカスタマイズされたメソッドが含まれていればよいため、クライアントは使用しないメソッドに依存する必要があります。

この記事の事例を読んだ後は、この方法を習得したと思います。さらに興味深い情報については、php 中国語 Web サイトの他の関連記事に注目してください。

推奨読書:

PHPの依存関係逆転ケースの詳細な説明

PHPでComposerパッケージを作成する手順の詳細な説明

以上がPHP インターフェース分離原則 (ISP) のユースケース分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。