Detaillierte Erklärung des PHP-Abhängigkeitsinversionsfalls

Dieses Mal werde ich Ihnen den Fall der PHP-Abhängigkeitsumkehr ausführlich erläutern. Was sind die Vorsichtsmaßnahmen für die PHP-Abhängigkeitsumkehr? Hier ist ein praktischer Fall, werfen wir einen Blick darauf.

Was ist Abhängigkeitsinversion? Vereinfacht ausgedrückt: kehrt die Abhängigkeitsbeziehung in eine Abhängigkeitsschnittstelle um

1. Das obere Modul sollte nicht vom unteren Modul abhängen alle hängen von einer Abstraktion ab (übergeordnete Klassen können nicht von Unterklassen abhängen, sie alle hängen von abstrakten Klassen ab)

2. Abstraktion kann nicht von Konkretheit abhängen, Konkretes sollte von Abstraktion abhängen.

Beachten Sie, dass

die Schnittstelle hier keine Schnittstelle im engeren Sinne ist.

Warum auf Schnittstellen setzen? Da die Schnittstelle die Abstraktion des Problems verkörpert und die Abstraktion im Allgemeinen relativ stabil ist oder sich relativ selten ändert, ist Beton veränderbar. Daher ist die Abhängigkeitsabstraktion die Grundlage für die Implementierung von Codeerweiterung und Laufzeitbindung (Polymorphismus): Solange eine Unterklasse der abstrakten Klasse implementiert ist, kann sie von allen Benutzern der Klasse verwendet werden. Dabei steht das Konzept der Skalierbarkeit im Vordergrund. Normalerweise bezieht sich Erweiterbarkeit auf die Erweiterung bekannter Verhaltensweisen. Wenn über Schnittstellen gesprochen wird, wird auch erwähnt, dass Schnittstellen relativ sein sollten. Dies zeigt uns, dass es unabhängig davon, wie fortgeschritten das

Entwurfsmuster verwendet wird, unmöglich ist, eine sich ständig ändernde Situation zu erreichen, ohne den Code zu ändern. Unter den fünf Prinzipien der Objektorientierung ist die Abhängigkeitsumkehr meiner Meinung nach am schwierigsten zu verstehen und umzusetzen.

Hier ist die Mitarbeiterklasse als Beispiel

<?php
interface employee
{
  public function working();
}
class teacher implements employee
{
  public function working()
  {
    echo &#39;teaching...&#39;;
  }
}
class coder implements employee
{
  public function working()
  {
    echo &#39;coding...&#39;;
  }
}
class workA
{
  public function work()
  {
    $teacher = new teacher();
    $teacher->working();
  }
}
class workB
{
  private $e;
  public function set(employee $e)
  {
    $this->e = $e;
  }
  public function work()
  {
    $this->e->working();
  }
}
$worka = new workA;
$worka->work();
$workb = new workB;
$workb->set(new teacher());
$workb->work();

In ArbeitA basiert die Arbeitsmethode auf der Lehrerimplementierung; in ArbeitB basiert Arbeit stattdessen auf der Abstraktion, sodass die erforderlichen Objekte übergeben werden können durch Parameter. Der obige Code erreicht über die Schnittstelle ein gewisses Maß an Entkopplung, ist jedoch immer noch begrenzt. Nicht nur durch die Verwendung von Schnittstellen, sondern auch durch die Verwendung von Fabriken kann ein gewisses Maß an Entkopplung und Abhängigkeitsumkehr erreicht werden.

In workB wird die Lehrerinstanz über die Set-Methode übergeben, wodurch der

Werksmodus realisiert wird. Da eine solche Implementierung immer noch fest codiert ist, schreiben Sie diese Abhängigkeit in die Konfigurationsdatei , um eine weitere Erweiterung des Codes zu erreichen. Dies gibt an, dass workB ein Lehrerobjekt benötigt, das speziell von einem Programm konfiguriert wird (wie gezeigt). ) Ob die abhängigen Klassendateien vorhanden sind) und die Implementierung, von der die Ladekonfiguration abhängt. Dieses Erkennungsprogramm wird als IOC-Container bezeichnet.

Ich habe das Konzept von IOC (Inversion of Control) in vielen Artikeln gesehen. Tatsächlich ist IOC ein Synonym für Dependence Inversion Principle (DIP). Wenn Sie IOC erwähnen, erwähnen Sie möglicherweise auch Konzepte wie DI. DI, also

Dependency Injection Es wird allgemein angenommen, dass Dependency Injection (DI) und Dependency Lookup (DS) zwei Implementierungen von IOC sind. Mit der Entwicklung einiger allgemeiner Konzepte ist die Beziehung zwischen diesen Konzepten jedoch verschwommen. Einige Leute denken, dass IOC DI ist. Einige Leute denken, dass die Beschreibung der Abhängigkeitsinjektion angemessener ist als die von IOC, und die Beziehung zwischen diesen Konzepten wird hier nicht verwickelt.

Im klassischen J2EE-Design werden die DAO-Schicht und die Servicen-Schicht normalerweise in die Schnittstellenschicht und die Implementierungsschicht unterteilt, und dann werden die Abhängigkeiten in der Konfigurationsdatei konfiguriert. Dies ist die häufigste DIP-Anwendung. Das Spring-Framework ist ein guter IOC-Container, der die Steuerung vom Code zum IOC-Fenster trennt. Dies wird durch XML-Konfigurationsdateien erreicht, die während der Ausführung Abhängigkeiten zwischen Objekten herstellen.

Wie im folgenden Code gezeigt

<bean scopre="prototype" class="cn.notebook.action.NotebookListOtherAction" id="notebookListOtherAction">
  <property ref="userReplyService" name="userReplyService" />
  <property ref="userService" name="userService" />
  <property ref="permissionService" name="permissionService" />
  <property ref="friendService" name="friendService" />
</bean>

Es gibt jedoch immer noch Probleme mit einer solchen Einstellung. Die Konfigurationsdatei wird immer größer und die Beziehung zwischen ihnen wird immer komplexer . Wir können uns auch dem Albtraum nicht entziehen, den Code ständig zu ändern, wenn sich die Anwendung und das Geschäft ändern (hier wird die Konfigurationsdatei als Teil des Codes betrachtet). Und in der tatsächlichen Entwicklung kommt es selten vor, dass die Konfigurationsdatei einfach geändert wird. Im Allgemeinen gilt, wenn die Wenn die Konfigurationsdatei geändert wird, wird der Code entsprechend geändert.)

In PHP gibt es auch eine ähnliche Implementierung wie Spring, das heißt, die Abhängigkeiten werden in die Konfigurationsdatei geschrieben und die erforderlichen Objekte werden über die Konfigurationsdatei generiert. Ich denke, dass ein solcher Code immer noch aus Gründen der Implementierung implementiert wird. In Srping konfiguriert die Konfigurationsdatei nicht nur die Laufzeitabhängigkeiten einer Klasse, sondern auch Transaktionsverwaltung, AOP, Lazy Loading usw. Um die oben genannten Funktionen in PHP zu erreichen, ist der Verbrauch enorm. Aus sprachlicher Sicht unterscheiden sich dynamische Skriptsprachen wie PHP von kompilierten Sprachen durch die Implementierung einiger polymorpher Funktionen. Zweitens legt PHP als agile Entwicklungssprache Wert auf schnelle Entwicklung, klare Logik und einfacheren und leichter verständlichen Code. Wenn verschiedene Designmuster-Frameworks hinzugefügt werden, ist dies aus Sicht der technischen Implementierung und Betriebseffizienz nicht ratsam. Das Kernprinzip der Abhängigkeitsinversion ist die Entkopplung. Von diesem primitivsten Prinzip abzuweichen bedeutet, das Pferd von hinten aufzuzäumen.

Tatsächlich ist das Prinzip der Abhängigkeitsumkehr bereits in vielen Entwurfsmustern enthalten. Wir führen auch absichtlich oder unabsichtlich einige Arbeiten zur Abhängigkeitsumkehr durch. Es ist nur so, dass es als PHP derzeit keinen relativ vollständigen IOC-Container gibt, vielleicht braucht PHP ihn überhaupt nicht.

Wenn DIP erfüllt ist:

1 Jede übergeordnete Klasse schlägt eine Schnittstellendeklaration für die Dienste vor, die sie benötigt, und niedrigere Klassen implementieren diese Schnittstelle.

2. Jede High-Level-Klasse nutzt Dienste über diese abstrakte Schnittstelle.

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 der Schritte zur Implementierung des Multi-Image-Uploads mit Bootstrap+PHP

Detaillierte Erläuterung von Schritte zur Implementierung der Warenkorbfunktion mit CI-Framework

Das obige ist der detaillierte Inhalt vonDetaillierte Erklärung des PHP-Abhängigkeitsinversionsfalls. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!