Eine eingehende Analyse der Erscheinungsmuster im Laravel-Framework

LaravelDas Fassadenmuster (Fassadenmuster) im Framework besteht darin, dass die externe Kommunikation mit einem Subsystem über ein einheitliches Fassadenobjekt erfolgen muss, um eine konsistente Schnittstelle für eine Reihe von Schnittstellen im Subsystem bereitzustellen. Das Fassadenmuster definiert eine High-Level-Schnittstelle, die die Verwendung dieses Subsystems erleichtert. Der Erscheinungsmodus wird auch Fassadenmodus genannt, bei dem es sich um einen Objektstrukturmodus handelt.

Fassaden Route, Redis und Auth, die wir üblicherweise in Laravel verwenden, sind die spezifischen Implementierungen des Erscheinungsmusters in Laravel, und jede Erscheinungsklasse erbt von der einheitlichen Die abstrakte Erscheinungsklasse bietet grundlegende Methoden für den Zugriff auf das dahinter liegende Subsystem über die Erscheinungsklasse.

Ändern Sie für neue Geschäftsanforderungen nicht die ursprüngliche Erscheinungsklasse, sondern fügen Sie eine neue spezifische Erscheinungsklasse hinzu. Die neue spezifische Erscheinungsklasse wird mit dem neuen Subsystemobjekt verknüpft und gleichzeitig erreicht Ändern der Konfigurationsdatei Der Zweck besteht nicht darin, den Quellcode zu ändern und die Erscheinungsklasse zu ersetzen.

Das Folgende ist ein Beispiel für ein einfaches Erscheinungsmuster, das keine abstrakte Erscheinungsklasse einführt. Im Artikel zur Einführung von Laravel Facade werden wir sehen, dass Laravel eine abstrakte Erscheinungsklasse bereitstellt, damit wir sie einfach anpassen können Fügen Sie entsprechend unseren Anforderungen die Erscheinungsklasse des neuen Subsystems hinzu und aktivieren Sie die Erscheinungsklasse als korrekten Proxy für das entsprechende Subsystem (oder den entsprechenden Dienst).

Modusstruktur

Der Erscheinungsmodus enthält die folgenden Rollen:

• Fassadenerscheinungsrolle

• SubSystem-Subsystemrolle

Codebeispiel

<?php class Client
{
    public function main()
    {
        (new Facade)->operation();
    }
}

class Facade
{
    private $systemA;
    private $systemB;
    
    public function __construct()
    {
        $this->systemA = new SystemA;
        $this->systemB = new SystemB;
    }
    
    public function operation()
    {
        $this->systemA->operationA();
        $this->systemB->operationB();
    }
}

class SystemA
{
    public function operationA()
    {
        //
    }
}

class SystemB
{
    public function operationB()
    {
        //
    }
}

Muster Analyse

Nach dem „Single-Responsibility-Prinzip“ ist die Aufteilung eines Systems in mehrere Subsysteme in der Software hilfreich, um die Komplexität des Gesamtsystems zu reduzieren. Ein gemeinsames Designziel besteht darin, die Kommunikation und gegenseitige Abhängigkeit zwischen Subsystemen auf ein Minimum zu reduzieren. Eine Möglichkeit, dieses Ziel zu erreichen, besteht darin, ein Fassadenobjekt einzuführen, das einen einfachen und einzigen Einstiegspunkt für den Zugriff auf das Subsystem bietet. -Der Erscheinungsmodus ist auch die Verkörperung des „Demeter-Gesetzes“. Durch die Einführung einer neuen Erscheinungsklasse kann die Komplexität des ursprünglichen Systems verringert und die Kopplung zwischen der Client-Klasse und der Subsystemklasse verringert werden. - Das Erscheinungsmuster erfordert, dass die Kommunikation zwischen der Außenseite eines Subsystems und seinem Inneren über ein einheitliches Erscheinungsobjekt erfolgt. Die Erscheinungsklasse trennt den Client von der internen Komplexität des Subsystems, sodass sich der Client nur mit der Erscheinung befassen muss Objekt ohne Arbeit mit vielen Objekten innerhalb des Subsystems. -Der Zweck des Darstellungsmodus besteht darin, die Komplexität des Systems zu reduzieren. -Der Darstellungsmodus verbessert die Benutzerfreundlichkeit durch den Client erheblich, sodass sich der Client nicht um die Arbeitsdetails des Subsystems kümmern muss und verwandte Funktionen über die Darstellungsrolle aufrufen kann.

Nachteile

Nachteile des Darstellungsmodus

• Kann Clients nicht gut daran hindern, Subsystemklassen zu verwenden, wenn Sie zu viel tun, damit Clients auf Subsystemklassen zugreifen können. Einschränkungen Variabilität und Flexibilität reduzieren.

• Ohne die Einführung einer abstrakten Erscheinungsklasse erfordert das Hinzufügen eines neuen Subsystems möglicherweise eine Änderung des Quellcodes der Erscheinungsklasse oder des Clients, was gegen das „Open-Close-Prinzip“ verstößt.

Mustererweiterungen

• Ein System hat mehrere Erscheinungsklassen

  Im Erscheinungsmodus wird normalerweise nur eine Erscheinungsklasse benötigt. und diese Erscheinungsklasse hat nur eine Instanz, mit anderen Worten, es ist eine Singleton-Klasse. Um Systemressourcen zu sparen, werden Erscheinungsklassen in vielen Fällen im Allgemeinen als Singleton-Klassen entworfen. Dies bedeutet natürlich nicht, dass es im gesamten System nur eine Erscheinungsklasse geben kann. Jede Erscheinungsklasse ist für die Interaktion mit bestimmten Subsystemen und die Bereitstellung entsprechender Geschäftsfunktionen für Benutzer verantwortlich.

• Versuchen Sie nicht, dem Subsystem neue Verhaltensweisen durch Erscheinungsklassen hinzuzufügen.

  Fügen Sie dem Subsystem keine neuen Verhaltensweisen hinzu, indem Sie eine Erscheinungsklasse erben. . Der Zweck des Erscheinungsmusters besteht darin, einen zentralisierten und vereinfachten Kommunikationskanal für Subsysteme bereitzustellen, anstatt dem Subsystem neue Verhaltensweisen hinzuzufügen. Das Hinzufügen neuer Verhaltensweisen sollte durch Ändern der ursprünglichen Subsystemklasse oder durch Hinzufügen einer neuen Subsystemklasse erreicht werden durch Erscheinungsklassen implementiert werden.

• Einführung abstrakter Erscheinungsklassen

  Der größte Nachteil des Erscheinungsmodus besteht darin, dass er das „Öffnungs- und Schließprinzip“ verletzt, das beim Hinzufügen neuer Subsysteme oder beim Entfernen erforderlich ist Subsysteme Eine Änderung der Erscheinungsklasse kann dieses Problem bis zu einem gewissen Grad lösen, indem abstrakte Erscheinungsklassen und Client-Programme für die abstrakten Erscheinungsklassen eingeführt werden. Für neue Geschäftsanforderungen wird die ursprüngliche Erscheinungsklasse nicht geändert, sondern eine neue spezifische Erscheinungsklasse wird dem neuen Subsystemobjekt zugeordnet. Gleichzeitig wird die Konfigurationsdatei geändert, um das Ziel zu erreichen Den Quellcode nicht ändern und den Zweck der Appearance-Klasse ersetzen.

Zusammenfassung

• Im Erscheinungsmodus muss die externe Kommunikation mit einem Subsystem über ein einheitliches Erscheinungsobjekt erfolgen, bei dem es sich um eine Gruppe von Subsystemen handelt, die die Schnittstelle bereitstellt eine konsistente Schnittstelle, und das Fassadenmuster definiert eine High-Level-Schnittstelle, die die Verwendung dieses Subsystems erleichtert. Der Erscheinungsmodus wird auch Fassadenmodus genannt, bei dem es sich um einen Objektstrukturmodus handelt.

• Der Auftrittsmodus enthält zwei Rollen: Die Auftrittsrolle ist eine Rolle, die direkt dem Kunden zugewiesen ist. In der Auftrittsrolle können Sie die Funktionen und Verantwortlichkeiten der relevanten (einen) kennen Es delegiert alle Anforderungen des Clients an das entsprechende Subsystem und leitet sie zur Verarbeitung an das entsprechende Subsystemobjekt weiter. Es kann eine oder mehrere Subsystemrollen gleichzeitig im Softwaresystem geben, möglicherweise nicht jedes Subsystem eine separate A-Klasse, sondern eine Sammlung von Klassen, die die Funktionen eines Subsystems implementiert.

• Das Erscheinungsmuster erfordert, dass die Kommunikation zwischen der Außenseite eines Subsystems und seinem Inneren über ein einheitliches Erscheinungsobjekt erfolgt. Die Erscheinungsklasse trennt den Client von der internen Komplexität des Subsystems. Erstellen des Clients Das Ende muss sich nur mit Erscheinungsobjekten befassen und muss sich nicht mit vielen Objekten innerhalb des Subsystems befassen.

• Der Hauptvorteil des Darstellungsmodus besteht darin, Subsystemkomponenten vor Kunden zu schützen, die Anzahl der von Kunden verarbeiteten Objekte zu reduzieren und die Verwendung des Subsystems zu vereinfachen. Er realisiert die Kommunikation zwischen Subsystem und Kunden Es koppelt die Beziehung lose, reduziert Kompilierungsabhängigkeiten in großen Softwaresystemen und vereinfacht den Transplantationsprozess von Systemen zwischen verschiedenen Plattformen. Der Nachteil besteht darin, dass es die Verwendung von Subsystemklassen durch Kunden nicht gut einschränken kann und keine abstrakten Erscheinungsklassen einführt. In einigen Fällen kann das Hinzufügen eines neuen Subsystems eine Änderung der Erscheinungsklasse oder des Client-Quellcodes erfordern, was gegen das „Öffnen-Schließen-Prinzip“ verstößt.

• Anwendbare Situationen des Erscheinungsmusters umfassen: Bereitstellung einer einfachen Schnittstelle für ein komplexes Subsystem; in einer hierarchischen Struktur besteht eine große Abhängigkeit Jede Schicht im System muss so definiert werden, dass keine direkte Verbindung zwischen den Schichten besteht.

Das Obige ist der gesamte Inhalt dieses Artikels. Weitere Informationen finden Sie im Laravel Framework Erste Schritte-Tutorial.

Empfohlene verwandte Artikel:

Parsen des Middleware-Quellcodes basierend auf Laravel5.2

Aufbau einer lokalen Laravel-Umgebung: Homestead Bereitstellung der Entwicklungsumgebung

Empfohlene verwandte Kurse:

Empfohlene fünf aktuelle Laravel-Video-Tutorials im Jahr 2017

Das obige ist der detaillierte Inhalt vonEine eingehende Analyse der Erscheinungsmuster im Laravel-Framework. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!