PHP の 5 つのオブジェクト指向原則のうち、インターフェイス分離原則 (ISP) の詳細な説明-PHPチュートリアル-php.cn

この記事では、主に PHP のオブジェクト指向インターフェイス分離原則 (ISP) を紹介し、インターフェイス分離の概念、原理、使用法、および関連する操作上の注意事項を詳細に分析します。必要な方は参考にしてください。例付きの PHP 指向 5 つの主な原則は、インターフェイス分離原則 (ISP) です。参考のために皆さんと共有してください。詳細は次のとおりです。

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

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

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

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

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

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

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

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

ログイン後にコピー

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

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

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

ログイン後にコピー

dog class:

<?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 class:

<?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();
}

ログイン後にコピー

これらのインターフェイスクラスを定義すると、dog と Fish の実装がはるかに簡単になります。

<?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): 単一の全体的なインターフェイスではなく、複数の特殊なインターフェイスを使用します。つまり、クライアントは必要のないインターフェイスに依存すべきではありません。

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