Anwendungsfallanalyse des PHP Interface Isolation Principle (ISP).

Dieses Mal werde ich die Anwendungsfälle des PHP-Schnittstellenisolationsprinzips (ISP) analysieren. Was sind die Vorsichtsmaßnahmen für die Verwendung des PHP-Schnittstellenisolationsprinzips (ISP)? sehen.

Wenn ein Modul beim Entwerfen einer Anwendung mehrere Untermodule enthält, sollten wir bei der Abstraktion des Moduls vorsichtig sein. Unter der Annahme, dass das Modul von einer Klasse implementiert wird, können wir das System in eine Schnittstelle abstrahieren. Wenn jedoch beim Hinzufügen einer neuen Modulerweiterung das hinzuzufügende Modul nur einige Untermodule des ursprünglichen Systems enthält, zwingt uns das System, alle Methoden in der Schnittstelle zu implementieren, und wir müssen einige dumme Methoden schreiben. Solche Schnittstellen werden als fette Schnittstellen oder verschmutzte Schnittstellen bezeichnet. Die Verwendung solcher Schnittstellen führt zu unangemessenen Verhaltensweisen im System. Diese unangemessenen Verhaltensweisen können zu falschen Ergebnissen führen und auch zu einer Verschwendung von Ressourcen führen.

1. Schnittstellentrennung

Das Schnittstellentrennungsprinzip (ISP) besagt, dass Kunden nicht gezwungen werden sollten, etwas zu implementieren, von dem sie nicht wissen, wie Zu tun Die verwendete Schnittstelle sollte die Methoden in der Fat-Schnittstelle gruppieren und sie dann durch mehrere Schnittstellen ersetzen, wobei jede Schnittstelle ein Submodul bedient. Einfach ausgedrückt ist es viel besser, mehrere spezialisierte Schnittstellen zu verwenden als eine einzelne Schnittstelle.

Die Hauptpunkte von ISP sind wie folgt:

1) Die Abhängigkeit einer Klasse von einer anderen Klasse sollte auf der kleinsten Schnittstelle basieren.

ISP kann das Ziel erreichen, Kunden (Schnittstellennutzungsmethoden) nicht dazu zu zwingen, sich auf Methoden zu verlassen, die sie nicht verwenden. Die Implementierungsklasse der Schnittstelle sollte nur eine Einzelverantwortungsrolle darstellen (gemäß SRP). Prinzip)

ISP kann auch die Interaktion zwischen Kunden reduzieren – wenn ein Kunde neue Verantwortlichkeiten benötigt (Änderungen erfordert) und eine Änderung der Schnittstelle erzwingt, ist die Möglichkeit einer Beeinträchtigung anderer Kundenprogramme minimal.

2) Das Client-Programm sollte sich nicht auf Schnittstellenmethoden (Funktionen) verlassen, die es nicht benötigt.

Das Client-Programm sollte von Schnittstellenmethoden (Funktionen) abhängig sein, die es nicht benötigt. Hängt von der benötigten Schnittstelle ab. Stellen Sie die Schnittstelle bereit, die der Kunde benötigt, und eliminieren Sie unnötige Schnittstellen. Dies erfordert eine Verfeinerung der Schnittstelle, um ihre Reinheit sicherzustellen.

Beim Erben erbt die Unterklasse beispielsweise alle verfügbaren Methoden in der übergeordneten Klasse und einige Methoden in der übergeordneten Klasse werden in der Unterklasse möglicherweise nicht benötigt. Beispielsweise erben sowohl normale Mitarbeiter als auch Manager von der Mitarbeiterschnittstelle. Mitarbeiter müssen jeden Tag Arbeitsprotokolle schreiben, Manager jedoch nicht. Daher können Arbeitsprotokolle nicht zum Blockieren von Managern verwendet werden, d. h. Manager sollten sich nicht auf die Methode zur Übermittlung von Arbeitsprotokollen verlassen.

Es ist ersichtlich, dass es bei ISP und SRP einige Überschneidungen in den Konzepten gibt. Tatsächlich überschneiden sich viele Entwurfsmuster konzeptionell, und es ist sogar schwierig zu erkennen, zu welchem ​​Entwurfsmuster ein Codeabschnitt gehört.

ISP betont, dass die Schnittstelle dem Kunden so wenig wie möglich verspricht und spezifisch sein muss. Wenn sich die Anforderungen eines Client-Programms ändern und eine Änderung der Schnittstelle erzwingen, ist die Wahrscheinlichkeit einer Beeinträchtigung anderer Client-Programme gering. Dabei handelt es sich tatsächlich um ein Problem der Schnittstellenverschmutzung.

2. Verschmutzung der Schnittstelle

Ein übermäßig aufgeblähtes Schnittstellendesign ist eine Verschmutzung der Schnittstelle. Die sogenannte Schnittstellenverschmutzung besteht darin, der Schnittstelle unnötige Verantwortlichkeiten hinzuzufügen. Wenn der Entwickler der Schnittstelle nur eine neue Funktion hinzufügt, um die Anzahl der Schnittstellenimplementierungsklassen zu reduzieren, führt dieses Design dazu, dass die Schnittstelle kontinuierlich „verschmutzt“ und „fett“ wird " .

„Schnittstellenisolation“ ist eigentlich das Prinzip des maßgeschneiderten Service-Designs. Verwenden Sie die Mehrfachvererbung von Schnittstellen, um verschiedene Schnittstellen zu kombinieren und externe Kombinationsfunktionen bereitzustellen – um „Dienste nach Bedarf“ zu erreichen.

Die Schnittstelle muss zerlegt werden, aber sie kann nicht zu fein zerlegt werden. Es muss ein Standard vorhanden sein, der eine hohe Kohäsion aufweist. Die Schnittstelle sollte über einige Grundfunktionen verfügen und in der Lage sein, eine Grundaufgabe eindeutig zu erledigen.

In praktischen Anwendungen werden Sie auf die folgenden Probleme stoßen: Wenn ich beispielsweise eine DAO-Implementierung benötige, die sich an mehrere Arten von Datenbanken anpassen kann, dann sollte ich zuerst eine Datenbankoperation-Schnittstelle implementieren, die dies vorschreibt einige Datenbanken Grundlegende Betriebsmethoden, wie z. B. Herstellen einer Verbindung zur Datenbank, Hinzufügen, Löschen, Ändern und Überprüfen, Schließen der Datenbank usw. Dies ist eine minimal funktionale Schnittstelle. Für einige Methoden, die nur für MySQL gelten, aber in anderen Datenbanken nicht vorhanden sind oder anderer Natur sind, wie z. B. die MySQL-pconnect-Methode, die möglicherweise in PHP verwendet wird, existiert das gleiche Konzept wie diese Methode in anderen Datenbanken nicht, daher diese Methode Es sollte nicht in dieser Basisschnittstelle erscheinen. Welche grundlegenden Methoden sollte diese Basisschnittstelle haben? PDO hat es Ihnen gesagt.

PDO ist eine abstrakte Datenbankschnittstellenschicht, die uns sagt, welche grundlegenden Methoden eine grundlegende Datenbankbetriebsschnittstelle implementieren sollte. Die Schnittstelle ist eine Abstraktion auf hoher Ebene, daher sollten die Methoden in der Schnittstelle universell, einfach und nicht leicht zu ändern sein.

Es gibt noch eine andere Frage: Wie sollten diese einzigartigen Methoden implementiert werden? Gemäß dem ISP-Prinzip können diese Methoden in einer anderen Schnittstelle vorhanden sein, wodurch diese „heterogen“ beide Schnittstellen gleichzeitig implementieren können.

Bei Schnittstellenverschmutzung können Sie diese beiden Verarbeitungsmethoden in Betracht ziehen:

Verwenden Sie die Delegation, um Schnittstellen zu trennen.

Verwenden Sie Mehrfachvererbung, um Schnittstellen zu trennen.

Im Delegationsmodus sind zwei Objekte an der Verarbeitung derselben Anfrage beteiligt. Das Objekt, das die Anfrage annimmt, delegiert die Anfrage zur Verarbeitung an ein anderes Objekt, z. B. den Strategiemodus, Proxy-Modus usw. Das Konzept der Delegation wird in beiden Fällen angewendet.

Werfen wir einen Blick auf die Beispiele

Sind Sie jemals auf eine sehr „fette“ Benutzeroberfläche gestoßen?

Zum Beispiel: Es gibt eine Schnittstelle zu Tieren, der Code lautet wie folgt:

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

Dog ist eine spezifische Implementierung dieser Schnittstelle:

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

ok, jetzt wir Was sollen wir tun, wenn wir einen Fisch erschaffen möchten, der schwimmen kann? Wir müssen die Schnittstelle ändern, was sich auch auf die Implementierung der Hundeklasse auswirkt, und Fisch muss auch die Walk- und Speak-Methoden implementieren, wie im folgenden Code gezeigt:

Animal-Schnittstellenklasse:

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

Hundeklasse:

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

Fischklasse:

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

Zu diesem Zeitpunkt zeigt die Animal-Schnittstellenklasse die Eigenschaften einer „fetten“ Schnittstelle. Die sogenannte Fat-Schnittstelle bedeutet eigentlich, dass die Schnittstelle Methoden definiert, die nicht von allen Implementierungsklassen benötigt werden. Genau wie die Animal-Schnittstellenklasse können einige Tiere nicht schwimmen, einige Tiere können nicht laufen und einige Tiere können nicht fliegen. Wenn diese Methoden in einer Animal-Schnittstellenklasse geschrieben sind, wird die spätere Erweiterung und Wartung eine Katastrophe sein.

Wie können also die oben genannten Probleme gelöst werden?

Es ist ganz einfach: Verfeinern Sie einfach die Schnittstelle und teilen Sie die Animal-Schnittstellenklasse in drei Schnittstellenklassen auf:

animalCanWalk-Schnittstellenklasse:

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

AnimalCanSwim-Schnittstellenklasse:

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

animalCanSpeak-Schnittstellenklasse:

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

Nach der Definition dieser Schnittstellenklassen wird die Implementierung von Hund und Fisch viel einfacher sein

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

Zusammenfassend:

Das Konzept des Interface Segregation Principle (ISP): Verwenden Sie mehrere spezialisierte Schnittstellen anstelle einer einzigen Gesamtschnittstelle, das heißt, der Client sollte sich nicht auf die Schnittstellen verlassen, die er nicht benötigt.

Bei der Verwendung des Schnittstellenisolationsprinzips müssen wir darauf achten, die Granularität der Schnittstelle zu kontrollieren. Wenn sie zu klein ist, führt dies zu einer Zunahme der Schnittstellen im System, was der Wartung nicht förderlich ist; die Schnittstelle sollte nicht zu groß und zu klein sein. Eine große Schnittstelle verstößt gegen das Schnittstellenisolationsprinzip, weist eine geringe Flexibilität auf und ist sehr unpraktisch. Im Allgemeinen muss die Schnittstelle nur Methoden enthalten, die für einen bestimmten Benutzertyp angepasst sind, und Clients sollten nicht gezwungen werden, sich auf Methoden zu verlassen, die sie nicht verwenden.

Ich glaube, dass Sie die Methode beherrschen, nachdem Sie den Fall in diesem Artikel gelesen haben. Weitere spannende Informationen finden Sie in anderen verwandten Artikeln auf der chinesischen PHP-Website!

Empfohlene Lektüre:

Detaillierte Erläuterung des PHP-Abhängigkeitsinversionsfalls

Detaillierte Erläuterung der Schritte zum Erstellen eines Composer-Pakets in PHP

Das obige ist der detaillierte Inhalt vonAnwendungsfallanalyse des PHP Interface Isolation Principle (ISP).. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!