Fragen zum Befehlsmuster (PHP)

Der Punkt des Befehlsmusters ist in der Lage, unterschiedliche Funktionen in ein Objekt (den Befehl) zu isolieren, so dass es über mehrere andere Objekte (die Befehlshaber) hinweg wiederverwendet werden kann. Normalerweise gibt der Commander auch einen Empfänger an den Befehl, z. ein Objekt, auf das der Befehl abzielt. Zum Beispiel:

Im obigen Beispiel ist CarWash der Commander. Das Auto ist der Empfänger und das Programm sind die eigentlichen Befehle. Natürlich hätte ich eine Methode doStandardWash () in CarWash haben können und jedem Befehl eine Methode in CarWash gegeben, aber das ist weniger erweiterbar. Ich müsste eine neue Methode und einen neuen Befehl hinzufügen, wenn ich neue Programme hinzufügen wollte. Mit dem Befehlsmuster kann ich einfach neue Befehle (Think Callback) übergeben und einfach neue Kombinationen erstellen:

Natürlich könnten Sie auch die Closures oder Funktoren von PHP verwenden, aber lassen Sie uns für dieses Beispiel bei OOP bleiben. Eine andere Sache, bei der die Befehle nützlich sind, ist, wenn Sie mehr als einen Commander haben, der die Befehlsfunktion benötigt, z. B.

Wenn wir die Waschlogik in den CarWash programmiert hätten, müssten wir nun den gesamten Code im Dude duplizieren. Und da ein Typ viele Dinge tun kann (weil er ein Mensch ist), wird die Liste der Aufgaben, die er erledigen kann, zu einer schrecklichen langen Klasse führen.

Oft ist der Commander selbst auch ein Befehl, so dass Sie einen Befehlsbündel erstellen und ihn zu einem Baum zusammenfassen können. Befehle bieten oft auch eine Undo-Methode.

Wenn ich jetzt auf Ihren LoginCommand zurückschaue, würde ich sagen, dass es nicht viel Sinn macht, das so zu machen. Sie haben kein Befehlsobjekt (es ist der globale Bereich) und Ihr Befehl hat keinen Empfänger. Stattdessen kehrt es zum Commander zurück (der den globalen Gültigkeitsbereich zum Empfänger macht). Dein Befehl funktioniert also nicht wirklich auf dem Empfänger. Es ist auch unwahrscheinlich, dass Sie die Abstraktion in einen Command benötigen, wenn die Anmeldung nur an einer Stelle erfolgt. In diesem Fall stimme ich zu, dass LoginCommand besser in einen Authentifizierungsadapter eingefügt wird, möglicherweise mit einem Strategie-Muster:

Sie könnten es etwas Command-like tun:

Sie könnten dem Benutzer natürlich die Methode authenticate hinzufügen, aber dann müssten Sie den Datenbankadapter für die Authentifizierung auf den Benutzer setzen, z. B.

Das wäre auch möglich, aber ich persönlich sehe nicht, warum ein Benutzer einen Authentifizierungsadapter haben sollte. Es klingt nicht wie etwas, das ein Benutzer haben sollte. Ein Benutzer verfügt über die Anmeldeinformationen, die für einen Authentifizierungsadapter erforderlich sind, aber nicht für den Adapter selbst. Die Übergabe des Adapters an die authenticate -Methode des Benutzers wäre jedoch eine Option:

Andererseits, wenn Sie ActiveRecord verwenden, dann wird Ihr Benutzer sowieso über die Datenbank Bescheid wissen, und dann könnten Sie einfach alles oben genannte ausgeben und den gesamten Authentifizierungscode in den Benutzer schreiben.

Wie Sie sehen, läuft alles darauf hinaus, wie Sie Ihre Anwendung einrichten. Und das bringt uns zum wichtigsten Punkt: Design Patterns bieten Lösungen für gängige Probleme und erlauben es uns, über diese zu sprechen, ohne zuerst viele Begriffe definieren zu müssen. Das ist cool, aber oft müssen Sie die Muster modifizieren, damit sie Ihr konkretes Problem lösen. Sie können Stunden damit verbringen, über die Architektur zu theoretisieren und welche Muster zu verwenden sind und Sie werden keinen einzigen Code geschrieben haben. Denken Sie nicht zu viel darüber nach, ob ein Muster zu 100% der vorgeschlagenen Definition entspricht. Stellen Sie sicher, dass Ihr Problem gelöst ist.