WordPress-Widgets: Objektorientierte Programmierung erkennen
Wenn Sie den ersten Beitrag dieser Reihe noch nicht gelesen haben, empfehle ich ihn, da wir damit beginnen, objektorientierten Code für WordPress durch die Verwendung der Widgets-API zu schreiben.
Die Serie wird ein paar Dinge festhalten:
- zeigen Ihnen das Grundgerüst eines Widgets und warum es objektorientiert ist,
- Besprechen Sie, welche Dinge Sie bemerken sollten und warum
- aktualisiere das Widget Boilerplate zuerst direkt auf dieser Seite und pushe es dann auf GitHub,
- Erstellen Sie ein Widget mithilfe der API mit der Boilerplate als Grundlage für unsere Arbeit.
Aber bevor ich das tue, möchte ich sicherstellen, dass jeder, der dies liest, mit den Kernprinzipien der objektorientierten Programmierung vertraut ist und alles hat, was zum Erstellen einer objektorientierten Lösung für WordPress erforderlich ist.
Dazu empfehle ich Folgendes:
- Zwei Säulen der objektorientierten Programmierung: Teil 1 von 2
- Zwei Säulen der objektorientierten Programmierung: Teil 2 von 2
- Abstrakte Klassen, Teil 1 – Abstraktes Verhalten
- Abstrakte Klassen, Teil 2 – Abstrakte Klassen und Schnittstellen
- Der unabhängige WordPress-Entwickler
Wenn Sie all diese Inhalte gelesen haben, großartig. Sie werden auf diesen Post und die kommenden Posts gut vorbereitet sein. Wenn nicht, kann es sein, dass der Rest dessen, was Sie lesen werden, einige Lücken aufweist, aber der Kern des Beitrags sollte klar genug sein.
Was ist der Deal, genau?
Hier ist die Sache: Letzte Woche habe ich ein bisschen Code zusammen mit einigen Informationen über die Widgets-API geteilt. Ich werde in diesem Beitrag noch einmal darauf eingehen, bevor wir uns aus zwei Gründen mit dem codierungsintensiveren Teil befassen:
- Ich möchte, dass jeder, der dies liest, auf derselben Seite ist, wenn es um das Schreiben von objektorientiertem Code geht (zumindest in diesem Zusammenhang).
- Mir ist bewusst, dass Menschen mit unterschiedlichem Hintergrund kommen, und ich möchte sicherstellen, dass wir alle so weit wie möglich auf derselben Seite sind, bevor wir fortfahren.
Wenn Sie Erfahrung mit dem Schreiben von objektorientiertem Code haben, insbesondere in fortgeschrittener Funktion, mag Ihnen dies einfacher erscheinen; andernfalls hoffe ich, dass dies Sie mit allem ausstattet, was Sie brauchen, um objektorientierte Praktiken nicht nur in Bezug auf diese API, sondern auch beim Lesen des Codes anderer zu erkennen.
So erkennen Sie objektorientierte Programmierung
Vielleicht ist eine natürliche erste Frage, warum wir in der Lage sein müssen, objektorientierte Programmierung zu erkennen, zu lesen oder zu verstehen, bevor wir sie tatsächlich schreiben?
Ein Wort zu schlechtem Code
Die kurze Antwort darauf lautet:
Sie müssen nicht, aber ich es ist hilfreich. Wenn Sie in der Lage sind, objektorientierte Programmierung zu lesen, haben Sie einen Vorsprung, wenn es darum geht, das, was sie als Paradigma bietet, zu nutzen, weil Sie auf den Strategien und der Arbeit anderer in anderen Projekten aufbauen werden.
Das bedeutet nicht, dass wir den schlechten Code nicht lesen, aber wir werden alles tun, um den schlechten Code zu identifizieren, die problematischen Bereiche zu identifizieren und dann alles zu tun, um zu vermeiden, dass wir ihn in unsere Arbeit integrieren.
Lassen Sie uns zunächst einen Blick auf die Widgets -API werfen, um zu sehen, was wir tun können, um objektorientierte Programmierung zu erkennen.
Zurück zur objektorientierten Programmierung
Im vorherigen Beitrag habe ich zwei Dinge skizziert, die darauf hindeuten, dass die API (zumindest bis zu einem gewissen Grad) objektorientiert ist:
- die Verwendung des Schlüsselworts extend,
- Funktionen, die wir implementieren müssen.
Der Grund, warum ich dieses Thema noch einmal aufgreifen möchte, ist, dass es zwei wichtige Dinge identifiziert, die Teil der objektorientierten Kernprinzipien sind: Vererbung und Funktionsimplementierung (die oft Teil abstrakter Klassen ist ).
Eine Anmerkung, bevor wir uns das Obige ansehen:
Wenn Sie sich die Quelle der Klasse WP_Widget ansehen, werden Sie feststellen, dass es keine abstrakten Methoden gibt. Aber einige der Funktionen, die wir implementieren müssen, die ich später in diesem Beitrag erwähnen werde, sind erstklassige Kandidaten für abstrakte Methoden. Und ich werde auch diskutieren, warum.
Trennen wir die obigen Themen in zwei separate Abschnitte: Vererbung und Abstraktionen.
Nachlass
Ich habe im vorherigen Beitrag davon gesprochen, dass Vererbung eine relative Tiefe ist, also werde ich den Punkt hier nicht weiter ausführen. Ich werde ein paar Worte sagen, aber ich bin viel mehr daran interessiert, über Abstraktion zu diskutieren, was ich gleich tun werde.
Bevor Sie jedoch zu weit darauf eingehen, lesen Sie bitte den folgenden Code:
Aber zuerst können wir erkennen, dass jede Klasse, die die Widgets-API implementiert, die Vererbung einfach wegen des Schlüsselworts extend verwenden muss.
Das bedeutet, dass es eine Funktionalitätsebene gibt, die wir erben (oder kostenlos bekommen) und eine Funktionalitätsebene, die wir selbst implementieren müssen.
Aus dem PHP-Handbuch :
Wenn Sie beispielsweise eine Klasse erweitern, erbt die Unterklasse alle öffentlichen und geschützten Methoden von der übergeordneten Klasse. Sofern eine Klasse diese Methoden nicht überschreibt, behalten sie ihre ursprüngliche Funktionalität bei.
Wenn Sie jedoch Funktionalität von einer Klasse erben, stellen Sie möglicherweise fest, dass es wichtig ist, den Konstruktor der übergeordneten Klasse (in unserer __construct- Funktion) strikt aufzurufen.
Aber das wirft auf, was ich für eines der wichtigsten Probleme bei der Vererbung in PHP halte (und der ganze Grund, warum ich diesen Abschnitt aufnehmen wollte): Müssen wir den übergeordneten Konstruktor explizit aufrufen?
Auch laut Handbuch:
Übergeordnete Konstruktoren werden nicht implizit aufgerufen, wenn die untergeordnete Klasse einen Konstruktor definiert. Um einen übergeordneten Konstruktor auszuführen, ist ein Aufruf von parent::__construct() innerhalb des untergeordneten Konstruktors erforderlich. Wenn das Kind keinen Konstruktor definiert, kann es wie eine normale Klassenmethode von der Elternklasse geerbt werden (wenn es nicht als privat deklariert wurde).
Aber wir können das vereinfachen. Vielleicht ist das leichter zu merken:
- Wenn unsere Klasse Vererbung verwendet, aber keinen Konstruktor definiert, wird der übergeordnete Konstruktor aufgerufen.
- Wenn unsere Klasse Vererbung verwendet, aber einen Konstruktor definiert, muss das übergeordnete Konstrukt explizit aufgerufen werden.
Oder vielleicht noch einfacher:
- Wenn unsere Klasse keinen Konstruktor definiert, verwendet der Code standardmäßig den Konstruktor der Eltern.
Sinn ergeben? Kurz gesagt, wenn wir unsere Eigenschaften, Initialisierung und unseren Code in einem Konstruktor definieren, sollte die erste Zeile des Konstruktors unserer Klasse ein Aufruf an den übergeordneten Konstruktor sein.
Abstraktion
Um es ganz klar zu sagen, der Quellcode der Klasse WP_Widget enthält keine abstrakten Methoden. Ein Teil davon hat damit zu tun, wie die Klasse aufgebaut ist, ein Teil davon hat mit der Abwärtskompatibilität und den Funktionen von PHP5 zu tun.
Dies bedeutet jedoch nicht, dass wir nicht erkennen können, welche Funktionen als abstrakt gekennzeichnet werden könnten. Tatsächlich denke ich, dass es ein Argument dafür ist, welche Klassen abstrakt gemacht werden sollten. Aber zuerst definieren wir abstrakte Funktionen.
Beim Erben von einer abstrakten Klasse müssen alle Methoden, die in der Klassendeklaration des Elternteils als abstrakt gekennzeichnet sind, vom Kind definiert werden; zusätzlich müssen diese Methoden mit der gleichen (oder weniger eingeschränkten) Sichtbarkeit definiert werden.
Wenn Sie sich die Quelle unseres Widgets ansehen:
Ich denke, es ist fair zu sagen, dass die Formularfunktion als abstrakt gekennzeichnet werden könnte, weil sie für unsere Implementierung einzigartig ist. Eine andere Möglichkeit, vom Standpunkt der Programmierung aus über abstrakte Funktionen nachzudenken, besteht darin, sich selbst zu fragen: Welche Funktionen erfordern eine einzigartige Funktionalität?
Und in diesem Fall ist die Formularfunktion genau das, weil jedes Widget in Bezug auf das, was es rendert, eindeutig anders ist. Die Widget- Funktion könnte auch als abstrakt gekennzeichnet werden, weil sie den Inhalt des Widgets ausgibt. Dieser Inhalt basiert natürlich auf der Funktionalität, die wir in unserer Implementierung implementiert haben.
Außerdem sagt der Quellcode der Klasse WP_Widget selbst:
Die Funktion WP_Widget::widget() muss in einer Unterklasse überschrieben werden.’
Dies ist genau die Art von Funktion, die als abstrakt gekennzeichnet werden sollte. Weil PHP einen Fehler auslöst, wenn eine Funktion als abstrakt markiert und nicht implementiert ist. Wir brauchten keine Funktionsaufrufe oder ähnliches.
Die anderen Funktionen müssen jedoch nicht unbedingt als abstrakt gekennzeichnet werden, und hier ist der Grund:
- __construct ruft den Konstruktor des übergeordneten Elements auf der grundlegendsten Ebene auf, und dies ist erforderlich, um die Basisklasse zu initialisieren. Vergessen Sie jedoch nicht; Wir können dieser Methode unsere Eigenschaften hinzufügen, die für unsere Klasse einzigartig sind.
- update verwendet die Funktionalität in der übergeordneten Klasse zum Serialisieren von Informationen.
Somit bleiben uns zwei Funktionen, die in einer moderneren Iteration der Klasse als abstrakt markiert werden könnten.
Next Up
An diesem Punkt sollten wir alle auf derselben Seite sein, was objektorientierten Code betrifft. Zumindest soweit wir durch eine Reihe von Blogbeiträgen kommen können.
Ab dem nächsten Beitrag werden wir uns wieder dem Schreiben von Code widmen.
Das heißt, wir werden das WordPress-Widget Boilerplate erneut besuchen und ich werde es in seinem aktuellen Zustand umgestalten, um modernere PHP-Standards zu übernehmen.
Ich werde die Änderungen mitteilen, die ich vornehme, die Begründungen dafür, und dann werde ich auch über die Art von Widget sprechen, das wir basierend auf der Boilerplate erstellen werden (und das können wir tun).