Heim  >  Artikel  >  Backend-Entwicklung  >  Detaillierte Erläuterung des Interface Isolation Principle (ISP) der fünf objektorientierten Prinzipien von PHP

Detaillierte Erläuterung des Interface Isolation Principle (ISP) der fünf objektorientierten Prinzipien von PHP

不言
不言Original
2018-04-04 17:24:021514Durchsuche

In diesem Artikel wird hauptsächlich das objektorientierte Schnittstellenisolationsprinzip (ISP) von PHP vorgestellt und das Konzept, das Prinzip, die Verwendung und die damit verbundenen Vorsichtsmaßnahmen für den Betrieb der Schnittstellenisolation im Detail analysiert. Freunde in Not können sich auf diesen Artikel beziehen

Das Beispiel beschreibt das Interface-Isolation-Prinzip (ISP) der fünf objektorientierten Prinzipien von PHP. Geben Sie es wie folgt als Referenz an alle weiter:

Wenn ein Modul beim Entwerfen einer Anwendung mehrere Untermodule enthält, sollten wir darauf achten, das Modul zu abstrahieren. 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, werden wir vom System gezwungen, 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 bestimmten 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 Datenbanktypen anpassen kann, sollte ich zunächst eine Datenbankbetriebsschnittstelle implementieren, die einige grundlegende Datenbanken festlegt Operationen Methoden wie Herstellen einer Verbindung zur Datenbank, Hinzufügen, Löschen, Ändern und Abfragen, 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.

Für die 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 akzeptiert, delegiert die Anfrage an ein anderes Objekt zur Verarbeitung. Die Delegation wird im Strategiemodus, im Proxy-Modus usw. 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 für Tiere. Der Code lautet wie folgt:

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

Hund gehört zu dieser Schnittstelle A spezifische Umsetzung:

<?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 wollen wir einen Fisch erschaffen, der schwimmen kann, was sollen wir tun? 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();
}

Hundekategorie:

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

Fischkategorie:

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

<?php
require_once "animalCanSwim.php";
class Fish implements AnimalCanSwim{
  public function swim(){
    echo "fish can swim";
  }
}

Um es zusammenzufassen:

Das Konzept des Interface Segregation Principle (ISP): Verwenden Sie mehrere spezialisierte Schnittstellen anstelle einer eine einzige Gesamtschnittstelle, d. h. der Client sollte sich nicht auf 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ß oder 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.

Verwandte Empfehlungen:

Detaillierte Erläuterung des Open-Closed-Prinzips (OCP) der fünf objektorientierten Prinzipien von PHP

Das obige ist der detaillierte Inhalt vonDetaillierte Erläuterung des Interface Isolation Principle (ISP) der fünf objektorientierten Prinzipien von PHP. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn