WordPress-Programmierung: Bedenken trennen

Wenn es darum geht, Klassen für WordPress-Plugins zu erstellen, wurde ich gefragt, warum ich mir die Mühe mache, die Funktionalität in Abonnenten und in andere Klassen zu unterteilen.

Ich denke, das ist eine gute Frage, weil sie hilft, zwei Dinge zu verstehen:

1. die Rolle eines Abonnenten in Bezug auf die WordPress-Architektur,
2. die Rolle der anderen Klassen in Bezug auf das, was Sie bauen (und wie dies bei anderen Dingen wie Unit-Tests und so weiter helfen kann).

Also dachte ich, warum nicht in Form eines kurzen Beitrags antworten? Es wird das Warum hinter dem Was dokumentieren [und es wird mir einen Platz zum Aktualisieren geben, wenn sich die Dinge in der Zukunft ändern].

WordPress-Programmierung: Abonnenten und Domänenobjekte

Ich betrachte die Klassen, die keine Abonnentendomänenobjekte sind, die aus dem Softwareentwicklungsansatz des domänengesteuerten Designs stammen.

Das liegt außerhalb des Rahmens dieses Beitrags, ist aber erwähnenswert, wenn auch aus keinem anderen Grund, weil es dem, was sonst als Fachjargon angesehen würde, einen gewissen Kontext gibt.

1 Abonnenten

Aber zuerst Abonnenten.

Da WordPress auf einem Hook-System basiert – einem System, das auf dem ereignisgesteuerten Designmuster basiert – ist es hilfreich, eine Klasse zu haben, die reagiert, wenn ein Ereignis ausgelöst wird.

Dies kann für jeden vordefinierten WordPress-Hook oder jeden benutzerdefinierten Hook sein. Es ist egal.

Und ich möchte die Klasse nicht komplizierter als nötig machen, also neige ich dazu, sie so zu betrachten:

Ein Abonnent antwortet immer dann, wenn ein bestimmtes Ereignis eintritt.

Und das ist es. Dieses Ereignis kann so etwas wie after_theme_setup oder the_content oder sogar init sein. Es spielt keine Rolle.

Es wartet darauf, dass ein Ereignis eintritt, und reagiert dann in dem, was wir entscheiden, durch die Verwendung von anderem Code (wobei Domain-Objekte ins Spiel kommen).

2 Domänenobjekte

Diese können auch Geschäftsobjekte oder ähnliches genannt werden. Die Idee dahinter ist folgende:

Alles, was wir in der objektorientierten Programmierung tun, soll ein bestimmtes Problem lösen, und zwar durch einen Objekttyp, der ein reales Objekt oder zumindest eine konkrete Idee darstellt.

Wenn Sie also daran arbeiten, jemandem eine Lösung bereitzustellen, sind die Klassen, die Sie schreiben – die Objekte, zu denen sie werden, wenn sie instanziiert werden – die Domänenobjekte.

Dies sind auch die Klassen, die die eigentliche Arbeit erledigen. Sie können es sich also in drei Komponenten vorstellen:

1. WordPress. Natürlich die Kernanwendung, die das Ereignis auslöst, auf das die Abonnenten reagieren.
2. Abonnenten. Der Satz von Klassen, die dafür verantwortlich sind, auf ein bestimmtes Ereignis zu lauschen und dann das richtige Objekt zu instanziieren, um den Code zu verarbeiten.
3. Domänenobjekte. Der Code, der tatsächlich die Arbeit erledigt, einen Datensatz zu nehmen, damit zu arbeiten und dann möglicherweise einen Wert zurückzugeben.

In den Domänenobjekten befindet sich der Code, um tatsächlich etwas zu tun. Die Abonnenten sind wie die Verbindung zwischen WordPress und besagter Funktionalität.

Abonnenten sagen: „Dieses Ereignis hat stattgefunden, und diese Klasse ist in der Lage und dafür verantwortlich, mit den Ergebnissen umzugehen.”

Was ist mit Tests und so weiter?

Weiter oben in diesem Beitrag habe ich darüber gesprochen, wie Domänenobjekte mit Unit-Tests und anderen Programmiertechniken im Zusammenhang mit der Qualitätskontrolle zusammenhängen.

Obwohl dies nicht der Beitrag für die Details ist, ist es erwähnenswert, dass die Trennung von Domänenobjekten und Abonnenten voneinander (und damit von WordPress) es uns ermöglicht, Objekte zu instanziieren, zu testen und mit Objekten zu arbeiten, die von aufgerufen werden Abonnenten, ohne WordPress in unsere Arbeit mitbringen zu müssen.

Und das kann beim Erstellen größerer Lösungen immens hilfreich sein. Aber das Wesentliche, wie das geht, ist Inhalt für einen anderen Beitrag.