Entkopplung der Domänenlogik in WordPress

Denken Sie daran, dass WordPress das ereignisgesteuerte Designmuster verwendet, und obwohl wir uns oft auf Aktionen und Filter beziehen, läuft das Konzept auf Hooks hinaus. Der Steuerungsfluss durch das Programm sieht ungefähr so ​​aus:

1. Führen Sie das Programm aus,
2. Immer wenn das Programm auf einen Hook stößt (in WordPress sehen wir do_actionoder apply_filters), durchlaufen Sie alle registrierten Hooks,
3. Geben Sie die Kontrolle wieder an das Programm zurück,
4. Bis zum Ende ausführen.

Dies unterscheidet sich nicht vollständig vom Publisher/Subscriber Pattern (oder kurz PubSub ), aber es gibt einen entscheidenden Unterschied: Das Event-Driven Pattern signalisiert einfach, dass etwas passiert ist, und wenn es Hooks gibt, werden sie ausgelöst. Das PubSub-Pattern weist einen registrierten Abonnenten an, etwas zu tun.

Wie auch immer, zurück zu Hooks in WordPress. Die zwei Konzepte von Hooks beizubehalten, die wir haben, kann am einfachsten bewerkstelligt werden, indem man sie sich so vorstellt:

• Aktionen sind dafür da, etwas zu tun,
• Filter dienen der Verarbeitung von Daten.

Wenn Sie die WordPress-Entwicklung objektorientiert angehen möchten, ist es keine gute Idee, Ihren Code eng an den WordPress-Kern zu koppeln, indem Sie Ihre Klassen über Hooks bei der Kernanwendung registrieren.

Mit anderen Worten: Registrieren Sie Ihre Geschäftslogik nicht bei WordPress. Halten Sie sie getrennt. Hier ist ein Lackmustest dafür, ob Ihre Arbeit eng mit WordPress gekoppelt ist: Wenn Sie keinen Komponententest für Ihre Klasse durchführen können, ohne WordPress zu laden, ist sie eng gekoppelt.

Also, was ist die Lösung? Delegation.

Domänenlogik in WordPress

Domänenlogik und Geschäftslogik sind für mich austauschbar. Wenn Sie also frühere Beiträge dazu gelesen haben und ich auf unterschiedliche Weise darüber gesprochen habe, wissen Sie warum.

Anerkennung

Als nächstes wird die Idee, Logik von WordPress an eine Klasse für Domänenlogik in WordPress zu delegieren, von einer Zwischenklasse durchgeführt, die für Folgendes verantwortlich ist:

1. Einen Haken abonnieren,
2. Delegieren der Arbeit an eine Klasse.

Ich weiß, dass der Unterricht „eine Sache gut” machen soll, aber was ist, wenn diese eine Sache das Delegieren ist?

einem anderen (Befugnisse, Funktionen etc.) als Bevollmächtigter zu übertragen

das Wörterbuch

Und um die Funktionalität ordnungsgemäß an einen anderen Agenten oder in unserem Fall an eine Klasse zu übertragen, müssen Sie wissen, was Sie delegieren. Manchmal müssen Sie mehrere Informationen kennen, um eine Sache zu tun.

Wie sieht das also praktisch aus? Stellen Sie sich vor, Sie haben ein [AbstractSubscriber](https://github.com/tommcfarlin/remove-empty-shortcodes/blob/master/src/Subscriber/AbstractSubscriber.php)to, das den Namen eines Hooks in seinen Konstruktor übernimmt:

Und wenn dies erledigt ist, loadsendet die Funktion die Arbeit an eine Klasse, die für die eigentliche Verarbeitung verantwortlich ist.

Nehmen Sie zum Beispiel diesen Code aus Remove Empty Shortcodes :

Eine Klasse abonniert ein bestimmtes Ereignis, z. B. [the_content](https://developer.wordpress.org/reference/functions/the_content/), und delegiert dann die Arbeit an die Klasse zur Verarbeitung von Post-Inhalten.

Dies ermöglicht es der Plugin-Bootstrap-Datei buchstäblich, den Delegaten zu instanziieren. Der Delegierte hängt sich dann in WordPress ein und wenn WordPress den richtigen Ausführungspunkt erreicht, sendet der Delegierte die Verantwortung an die Klasse, die für die Verarbeitung verantwortlich ist.

Diese gesamte Architektur ist nicht nur vollständig wiederverwendbar (siehe die Verwendung einer abstrakten Klasse oben), sondern ermöglicht es uns, die Domänenlogik von WordPress zu entkoppeln und isoliert zu testen.

Mehr zur Trennung von Interessen

Ich habe einige andere Beiträge zur Trennung von Bedenken geschrieben:

• Trennung von Bedenken mit WordPress-Vorlagen
• Trennung von Concerns mit Abfragen und Hilfsfunktionen
• WordPress-Programmierung: Bedenken trennen