WordPress-Widgets: Refactoring, Teil 3

In Bezug auf die Aktualisierung des WordPress Widget Boilerplate (das alles im Entwicklungszweig verfolgt wird) haben wir einen langen Weg zurückgelegt, was die Umgestaltung seiner Organisation betrifft.

Bisher haben wir:

• betrachtete, wie die WordPress-Widget-API ein Beispiel für objektorientierte Programmierung bietet,
• wie wir diese API verwenden können , um die objektorientierte Programmierung in anderen Bereichen von WordPress zu bestimmen,
• installierte Tools, die uns helfen, die Qualität des Codes zu bewerten,
• gefundene Fehler, die derzeit im Code in Bezug auf moderne Programmierstandards vorhanden sind,
• und begann damit, die Codebasis neu zu organisieren, damit sie moderneren Praktiken entspricht .

Jetzt sind wir bereit, diesen Code viel objektorientierter umzugestalten.

Wenn Sie also die vorherigen Posts (eigentlich alle) noch nicht gelesen haben, empfehle ich Ihnen, dies zu tun, da es eine Weile dauern wird, dies auf den neuesten Stand zu bringen. Es gibt eine Menge Code zu schreiben und zu erklären.

Lass uns anfangen.

Das WordPress-Widget Boilerplate: Refactoring, Teil 3

Das wohl größte Problem mit dem Boilerplate ist, dass alles in einer einzigen Klasse gekapselt ist.

Sicher, es gibt einige nette Dinge wie die Trennung unserer Ansichten von der serverseitigen Logik, aber das ist auch schon alles.

Andere Probleme, die nur beim Betrachten des Codes auftreten, sind:

• Hinzufügen von Aktionen und Filtern im Konstruktor,
• Methoden haben, die mehr als eine Sache tun,
• keine Klassen haben, die für die Implementierung von Dingen wie das Registrieren von Abhängigkeiten verantwortlich sind,
• usw.

In diesem Beitrag werden wir mit dem Prozess der Erstellung von Abstraktionen beginnen, die wir schließlich implementieren werden, um die gottklassenähnliche Natur der Boilerplate, so wie sie ist, aufzubrechen.

Dies wird in mehrere Posts aufgeteilt, damit ich in der Lage bin, eine solide Erklärung dafür zu geben, warum wir bestimmte Dinge tun, die wir tun, und die Beispiele dahinter zu erläutern.

Wenn ich es anders mache, lässt die Serie zu viele wertvolle Informationen aus, die auf andere objektorientierte Programmierpraktiken anwendbar sind.

Was ist ein Abonnent?

Das Hook-System von WordPress – also die Aktionen und Filter, die uns zur Verfügung stehen – basiert auf einem ereignisgesteuerten Designmuster. Das bedeutet, dass jedes Mal, wenn etwas passiert, ein Ereignis, WordPress jeden anderen Code auslöst, der dieses Ereignis abonniert hat.

Wenn wir also eine Funktion mit einem Hook registrieren, abonnieren wir das Ereignis. Zu diesem Zweck bin ich ein Fan davon, Abonnenten für jeden beliebigen Hook zu erstellen, den wir brauchen werden.

Darüber hinaus folgen Abonnenten im Allgemeinen einem einheitlichen Format. Das bedeutet, dass es wirklich einfach ist, eine abstrakte Klasse zu erstellen, die einen Teil der konsistenten Funktionalität implementiert, und es dann der Klasse, die die abstrakte Klasse implementiert, ermöglicht, sich ausschließlich auf die Geschäftslogik zu konzentrieren.

Eine der einfachsten Möglichkeiten, dies zu demonstrieren, ist das Abonnieren von CSS-Dateien und JavaScript-Dateien, da dies zwei der häufigsten Dinge sind, die wir beim Erstellen von Plugins verwenden.

Erstellen einer abstrakten Klasse

Lassen Sie uns vor der Implementierung der abstrakten Klasse genau darlegen, was wir tun werden, um diese zu erstellen.

1. Wir benötigen eine Eigenschaft, die das Ereignis darstellt, das wir abonnieren.
2. Wir brauchen eine Funktion, die ausgelöst wird, wenn der Hook von WordPress ausgelöst wird. Eine andere Denkweise ist, dass wir eine Funktion benötigen, die immer dann implementiert wird, wenn eine bestimmte Aktion oder ein bestimmter Filter von WordPress ausgelöst wird.
3. Wir brauchen Klassen, um die Abstraktion zu implementieren.

Lassen Sie uns zunächst abstrakte Klassen definieren. Direkt aus dem PHP-Handbuch lesen wir:

Als abstrakt definierte Klassen dürfen nicht instanziiert werden, und jede Klasse, die mindestens eine abstrakte Methode enthält, muss ebenfalls abstrakt sein. Als abstrakt definierte Methoden deklarieren einfach die Signatur der Methode – sie können nicht die Implementierung definieren.

Kurz gesagt bedeutet dies, dass wir keine Instanz einer abstrakten Klasse erstellen können. Wir können nur Klassen instanziieren, die die Implementierung definieren.

Das heißt aber nicht, dass die abstrakte Klasse keine konkreten Dinge (wie etwa die Definition eines Hooks) implementieren kann. Aber es bedeutet, dass es bestimmte Methoden gibt, die keine Implementierung haben.

Ansonsten bleibt uns nur eine Grundklasse.

Sinn ergeben? Lass uns einen Blick darauf werfen.

Erstellen einer abstrakten Klasse

Für diesen Beitrag erstellen wir eine abstrakte Klasse speziell für CSS-Dateien und JavaScript.

Denken Sie daran, da dies eine abstrakte Klasse ist, können die konkreten Abonnenten etwas genannt werden, das identifiziert, was sie tun (das heißt, sie können sich selbst alles nennen, was ihren Zweck repräsentiert). Und dazu kommen wir noch.

Aber zuerst die abstrakte Klasse. Ich werde den Code teilen und dann genau erklären, was damit los ist:

1. Beachten Sie, dass die von uns erstellte Eigenschaft protected ist. Dies ist so, dass implementierende Klassen darauf zugreifen können, aber alles außerhalb davon nicht.
2. Ich habe eine Funktion zum Abrufen des Hakens erstellt, die später deutlich wird. Normalerweise hasse ich es, Funktionen zu implementieren, die nicht sofort offensichtlich sind, aber das ist etwas, das wichtig ist, wenn man bedenkt, wohin wir gehen.
3. Es gibt eine abstrakte Funktion namens load. Hier wird jede Klasse, die diese Funktion implementiert, ihre Geschäftslogik unterbringen, wie wir gleich sehen werden.
4. Ich dokumentiere gerne den Zweck der Funktionen, wenn es nötig ist, damit sie sich an einem Ort befinden, und lasse dann die implementierenden Klassen die Dokumentation bereitstellen, die sie für ihre Implementierung benötigen. Sie werden dies auch gleich sehen.

Nachdem wir die abstrakte Klasse eingerichtet haben, müssen wir als letztes sicherstellen, dass sie im richtigen Verzeichnis und mit dem richtigen Namensraum abgelegt wird. Wenn Sie ab dem vorherigen Beitrag mitverfolgt haben, konnten Sie wahrscheinlich anhand des Namespace im Code erraten, wo es sich befinden wird.

Und wenn nicht, keine Sorge. Das Herausfinden von Namespaces und was nicht, kann ein wenig Zeit in Anspruch nehmen. Ich hoffe also, dass es durch diese Mitgliedschaftsbeiträge und diese Beispiele mit der Zeit klar wird.

Konkrete Klassen erstellen

Lassen Sie uns nun diese bestimmte Klasse implementieren, um sowohl die Stylesheets als auch die vorhandenen JavaScript-Quellen hinzuzufügen. Was Sie jedoch bemerken werden, ist, dass sie sich sehr ähnlich sind.

Das einzige, was sich unterscheidet, ist die Implementierung der Ladefunktion, die genau so funktionieren sollte.

Stylesheets

Angesichts der obigen abstrakten Klasse müssen wir jetzt eine Klasse zum Registrieren von Stylesheets erstellen. Da wir zwei Stylesheets haben, werden wir zwei Klassen erstellen:

1. Die erste Klasse ist für die Registrierung des Stylesheets für das Dashboard und insbesondere für die Seite des WordPress-Widgets verantwortlich.
2. Die zweite Klasse ist für die Registrierung des Plugins für das eigentliche Blog verantwortlich.

Nennen wir diese AdminStylesheetSubscriber bzw. PublicStylesheetSubscriber.

Zuerst der Admin-Stylesheet-Abonnent :

Beachten Sie, dass dies die Funktion get_current_screen() verwendet, die ich in früheren Beiträgen verwendet habe, um sicherzustellen, dass wir Abhängigkeiten nur dort hinzufügen, wo es notwendig ist.

Nun, der öffentliche JavaScript-Abonnent. Dies verwendet die Funktion is_admin(), um sicherzustellen, dass wir uns nicht im Verwaltungsbereich von WordPress befinden.

Offensichtlich müssen wir diese Klassen noch tatsächlich instanziieren. Das kommt später in der Serie.

JavaScript

Die JavaScript-Abonnenten sind nicht viel anders, wie Sie vielleicht vermutet haben. Wir trennen sie nach dem Bereich der Anwendung, auf den sie sich konzentrieren, und benennen sie entsprechend.

Zuerst der Admin-JavaScript-Abonnent :

Und der öffentliche JavaScript-Abonnent:

Auch diese Klassen können noch nicht instanziiert werden, aber wir werden uns in einem kommenden Beitrag darauf konzentrieren.

Abstraktionen und Schnittstellen

Denken Sie daran, dass Abstraktionen und Schnittstellen unterschiedlich sind, aber leicht verwechselt werden können. Schnittstellen enthalten absolut keine Implementierung. Stattdessen bieten sie eine Garantie dafür, dass jede Klasse, die die Schnittstelle implementiert, alle Methoden implementiert.

Bei abstrakten Klassen hingegen können einige Funktionen in der abstrakten Klasse implementiert werden, während der domänenspezifische Code – wie das Laden von Stylesheets und JavaScript – der entsprechenden Methode überlassen wird.

Dies wird deutlich, wenn es nicht bereits der Fall ist, je weiter wir in diese Serie einsteigen. Vergessen Sie in der Zwischenzeit – und wie üblich – nicht, den Entwicklungszweig zu überprüfen, um zu sehen, wo wir mit dem Code stehen.