Students Save 30%! Learn & create with unlimited courses & creative assets Students Save 30%! Save Now
Advertisement
  1. Code
  2. WordPress Plugins
Code

Objektorientiertes Autoloading in WordPress, Teil 2

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called Object-Oriented Autoloading in WordPress.
Object-Oriented Autoloading in WordPress, Part 1
Object-Oriented Autoloading in WordPress, Part 3

German (Deutsch) translation by Wei Zhang (you can also view the original English article)

Im vorherigen Tutorial haben wir eine Handvoll Konzepte behandelt, die alle notwendig sind, um zu verstehen, was wir in diesem Tutorial machen.

Insbesondere haben wir folgende Themen behandelt:

  • objektorientierte Schnittstellen
  • das Prinzip der einheitlichen Verantwortung
  • wie diese in PHP aussehen
  • wohin wir mit unserem Plugin gehen

In einigen Serien ist es einfach, Tutorials zu überspringen, die nicht aufeinander aufbauen können. Diese Serie soll jedoch nicht so sein. Stattdessen soll es in sequenzieller Reihenfolge gelesen werden, und es soll auf dem Inhalt jedes vorherigen Tutorials aufbauen.

Mit dem gesagt, ich nehme an, Sie sind alle gefangen.

Fertig machen

Auch wenn ich dies im ersten Tutorial erwähnt habe, möchte ich dennoch sicherstellen, dass wir alle auf der gleichen Seite sind, was das, was wir in jedem Tutorial tun und welche Software du brauchst.

Unsere Roadmap

Also in diesem Tutorial ist der Plan wie folgt:

  1. Untersuchen Sie den Code, den wir bisher geschrieben haben.
  2. Bestimmen Sie, wie wir es mithilfe von objektorientierten Techniken umgestalten können.
  3. Geben Sie die grobe Gliederung für unsere Implementierung an.

Letztendlich werden wir in diesem Tutorial nicht viel Code schreiben, aber wir werden einiges schreiben. Es ist jedoch ein praktisches Tutorial, in dem wir objektorientierte Analyse und Design durchführen. Dies ist eine notwendige Phase für viele große Projekte (und etwas, das für kleine Projekte passieren sollte).

Was du brauchst

Wenn Sie mitbekommen haben, sollten Sie dies bereits eingerichtet haben. Aber um sicherzugehen, hier ist die kurze Version von allem, was Sie brauchen:

  • eine lokale Entwicklungsumgebung, die für Ihr Betriebssystem geeignet ist
  • ein Verzeichnis, aus dem WordPress 4.6.1 gehostet wird
  • ein Texteditor oder eine IDE
  • Kenntnisse der WordPress Plugin API

Mit all dem sind wir bereit, an dem im vorherigen Tutorial geteilten Code zu arbeiten. Also lasst uns anfangen.

Den Code analysieren

Als allererstes wollen wir den aktuellen Zustand unseres Autoloaders analysieren. Es mag so aussehen, als würde viel Code in einen einzelnen Codeblock eingefügt, aber das allein zeigt uns, dass wir etwas zu tun haben.

Hier ist der aktuelle Status unseres Autoloaders:

Beachten Sie an dieser Stelle, dass das Prinzip der einheitlichen Verantwortlichkeit Folgendes besagt:

Eine Klasse sollte nur einen Grund haben, sich zu ändern.

Im Moment haben wir nicht einmal eine Klasse, geschweige denn mehrere individuelle Methoden, die nur einen einzigen Grund haben, sich zu ändern.

Und obwohl es sinnvoll sein könnte, diese Autoloader-Methode in kleinere, individuelle Methoden zu zerlegen, sollten wir von einer höheren Ebene aus beginnen und beginnen, über einen Autoloader in Bezug auf eine Schnittstelle nachzudenken. Dann werden wir eine Klasse (oder Klassen) erstellen.

Objektorientierte Analyse: Verantwortlichkeiten

Erinnern Sie sich aus dem vorherigen Tutorial, dass eine Schnittstelle wie folgt im PHP-Handbuch definiert ist:

Mit Objektschnittstellen können Sie Code erstellen, der angibt, welche Methoden eine Klasse implementieren muss, ohne definieren zu müssen, wie diese Methoden gehandhabt werden.

Lassen Sie uns angesichts des Codes und der obigen Definitionen darüber nachdenken, was ein Autoloader aus einer eher modularen Perspektive zu tun hat. Insbesondere lassen Sie uns die Punkte in Punkte aufteilen, die für eine Änderung ausreichen. Nein, wir können nicht alle diese Punkte verwenden, aber deshalb nennt man das Analyse. Wir werden später an dem Entwurf arbeiten.

Der Code macht folgendes:

  1. Validiert, dass wir explizit mit unserem Namespace arbeiten.
  2. Teilt den eingehenden Klassennamen in Teile auf, um festzustellen, ob es sich um eine Klasse oder eine Schnittstelle handelt (also ist $class_name ein schlechter Variablenname).
  3. Überprüft, ob wir mit einer Schnittstellendatei arbeiten.
  4. Überprüft, ob wir mit einer Klassendatei arbeiten.
  5. Prüft, ob wir mit einer Schnittstelle arbeiten.
  6. Basierend auf dem Ergebnis der obigen Bedingungen, wird ein Dateiname generiert.
  7. Erstellt einen Dateipfad basierend auf dem generierten Dateinamen.
  8. Wenn die Datei unter dem generierten Namen existiert, wird sie eingeschlossen.
  9. Andernfalls erzeugt der Code einen Fehler.

Daher macht der obige Code neun Dinge - das heißt, er hat mindestens neun Gründe, die geändert werden müssen - bevor er seine Arbeit erledigt hat.

Dies sollte selbstverständlich sein, aber diese spezielle Funktion ist ein perfektes Beispiel, das wir umgestalten können, um objektorientierte Analyse, Design, Schnittstellen und Implementierung zu demonstrieren.

Und das wirft eine Frage auf: Wo fangen wir überhaupt an?

Objektorientierte Analyse

An diesem Punkt ist es fair zu sagen, dass wir anfangen können, objektorientierte Analysen zu machen - das heißt, welche möglichen Klassen wir haben und wie sie interagieren -, wenn wir alles, was wir oben aufgelistet haben, geben. Denken Sie daran, wir wollen auch, dass das Prinzip der einheitlichen Verantwortung uns bei unseren Entscheidungen hilft.

An diesem Punkt sind wir nicht so sehr besorgt darüber, wie die Klassen miteinander kommunizieren werden. Stattdessen konzentrieren wir uns mehr auf das Erstellen von Klassen, die nur einen Grund haben, sich zu ändern.

Nachdem ich das gesagt habe, werde ich eine Auswahl von Klassen bereitstellen, von denen ich denke, dass sie funktionieren könnten. Bevor Sie weitermachen, schauen Sie sich an, was wir getan haben, und versuchen Sie, Ihre eigene Liste zu erstellen. Dann können wir Notizen vergleichen.

Ein Wort über Fähigkeiten

Beachten Sie, dass Sie möglicherweise eine bessere Idee haben als die unten aufgeführten, oder dass Sie etwas von dem entfernen, was wir geteilt haben. Unabhängig davon ist dies eine Lernübung. Wir versuchen, unseren Code, unsere Organisation zu verbessern und letztendlich bessere Programmierer zu werden.

Unsere potenziellen Klassen

Angesichts dessen, was ich oben aufgelistet habe, habe ich folgende Klassen entwickelt:

  1. Autoloader. Dies ist die Hauptklasse, die letztendlich dafür zuständig ist, unsere Klasse, unseren Namespace oder unsere Schnittstelle zu integrieren. Wir nennen diese Klasse. Der Rest sind Klassen, die sich um die notwendige Arbeit kümmern, die diese eine Klasse braucht, um die Datei zu enthalten.
  2. NamespaceValidator. Diese Datei wird die eingehende Klasse, Schnittstelle oder was Sie haben, und wird feststellen, ob es gültig ist. Dies wird uns den entscheidenden Faktor geben, wenn wir mit dem Rest unseres Codes nicht fortfahren können.
  3. FileInvestigator. Diese Klasse untersucht den Dateityp, der an den Autoloader übergeben wird. Es bestimmt, ob es sich um eine Klasse, eine Schnittstelle oder einen Namespace handelt, und gibt den vollständig qualifizierten Pfadnamen an die Datei zurück, damit sie eingeschlossen werden kann.
  4. FileRegistry. Dies verwendet den vollständig qualifizierten Dateipfad, der letztendlich von den anderen Klassen zurückgegeben wird, und fügt ihn in das Plugin ein.

Und das ist es. Jetzt müssen Drittanbieter-Klassen in unserem Plugin nur über die Autoloader-Klasse Bescheid wissen, aber der Autoloader benötigt Kenntnisse einer anderen Klasse, und andere Klassen benötigen Kenntnisse von noch anderen Klassen.

Es gibt Möglichkeiten, dies zu handhaben (mit Dependency-Injection-Containern, aber das geht über den Rahmen dieses Projekts hinaus). Aber was wir durch unseren Code erreichen wollen, ist die Minimierung, wie viele Klassen voneinander wissen.

Objektorientiertes Design

Zu diesem Zeitpunkt werden verschiedene Entwickler, Firmen, Agenturen und Teams einen anderen Ansatz verfolgen, wie sie das System entwickeln, an dem sie arbeiten.

Eine der gebräuchlichsten Methoden ist die Verwendung eines sogenannten UML-Diagramms. Obwohl es nützlich ist, ist es im Rahmen dieses Tutorials nicht sinnvoll, es zu tun, da es ein ganz anderes Tutorial erfordert, um alle Teile zu erklären.

Für die Zwecke unseres Tutorials, und da wir mit so wenig Code arbeiten, werden wir versuchen, herauszufinden, wie jede der oben genannten Klassen funktionieren könnte, bevor wir sie implementieren. Auf diese Weise erhalten wir eine Vorstellung davon, wie wir unseren Code organisieren können.

Beachten Sie, dass wir diesen Code noch nicht mit einem Namespace versehen, und dass dieser Code noch nicht für WordPress implementiert oder getestet wurde. Darauf werden wir im nächsten Tutorial eingehen.

Beginnen wir mit dem Autoloader und arbeiten von dort aus.

Autoloader

Denken Sie daran, dass diese Klasse für die Aufnahme der notwendigen Datei zuständig ist. Dies ist die Datei, die mit der Funktion spl_autoload_register registriert wird.

Beachten Sie, dass diese Klasse von der NamespaceValidator- und der FileRegistry-Klasse abhängt. Wir werden jeden von ihnen in einem Moment detaillierter sehen.

NamespaceValidator

Diese Datei untersucht den eingehenden Dateinamen und ermittelt, ob dieser gültig ist. Dies geschieht durch Betrachten des Namensraums im Dateinamen.

Wenn die Datei tatsächlich zu unserem Namensraum gehört, können wir annehmen, dass es sicher ist, unsere Datei zu laden.

FileInvestigator

Diese Klasse macht ziemlich viel Arbeit, obwohl ein Teil davon über sehr einfache, sehr kleine Hilfsmethoden erledigt wird. Während der Ausführung wird der Dateityp überprüft, den er übergeben hat.

Es ruft dann den vollständig qualifizierten Dateinamen für den Dateityp ab.

Wenn es eine Datei gibt, die ein bisschen mehr refaktoriert werden kann, dann ist es das. Immerhin versucht es festzustellen, ob wir mit einer Klasse, einer Schnittstelle oder einer Klasse arbeiten. Eine einfache Fabrik könnte dafür besser geeignet sein.

Wenn es Zeit wird, unseren Code zu implementieren, werden wir das vielleicht noch einmal umgestalten. Bis dahin ist dies ein vorläufiger Entwurf, der gut genug funktionieren kann.

FileRegistry

Dies wird den vollständig qualifizierten Dateipfad verwenden und die Datei einschließen; Andernfalls wird die WordPress-API verwendet, um eine Fehlermeldung anzuzeigen.

Eine andere Alternative zur Verwendung der WordPress-API wäre das Erstellen einer benutzerdefinierten Exception-Nachricht. Auf diese Weise können wir unseren Code vollständig von WordPress trennen oder entkoppeln.

Dieser Code ist wiederum ein Übertrag vom ursprünglichen Autoloader. Während der Implementierung können wir dies ebenfalls ändern.

Fazit

Alles klar, wir haben uns den vorhandenen Code für unseren Autoloader angesehen und dann einen möglichen Code herausgearbeitet, den wir aufgrund objektorientierter Analyse und Design verwenden können.

Ist die Lösung, auf die wir hinarbeiten, wartungsfreundlicher als das, was wir haben? Absolut. Wird dies im Kontext von WordPress und unserem bestehenden Plugin funktionieren? Wir werden es nicht wissen, bis wir anfangen, das in unser Plugin zu integrieren.

Wie bereits erwähnt, gibt es noch einige Bereiche, in denen wir diesen Code möglicherweise umgestalten könnten. Wenn wir diese Art von Problemen bei der Implementierung unseres Codes in der endgültigen Version unseres Plugins treffen, werden wir genau das tun.

Was auch immer der Fall ist, der Code, den wir jetzt haben, sollte besser lesbar sein (obwohl wir immer noch DocBlocks und einige Inline-Kommentare haben) und wartbarer und noch testbarer.

Mit all dem Gesagten hoffe ich, dass dies Ihnen eine Idee gegeben hat, wie Sie eine lange Methode anwenden und sie in zielgerichtetere Klassen aufteilen können. Sicher, mehrere Klassen mögen sich auf den ersten Blick seltsam anfühlen, aber das bedeutet nicht, dass es eine schlechte Sache ist. Haben Sie mehr Dateien (und damit Klassen) mit weniger Code als eine Datei mit viel Code ist besser.

Nehmen Sie die kontraintuitive Natur der objektorientierten Programmierung in diesem Zusammenhang auf. Im nächsten Tutorial werden wir zu unserem Plugin zurückkehren und daran arbeiten, eine Variation des obigen Codes zu implementieren. Wir werden wahrscheinlich auch etwas davon debuggen. Schließlich bekommen wir es beim ersten Mal selten richtig

Bis dahin, wenn Sie mehr über objektorientierte Programmierung im Kontext von WordPress lesen möchten, finden Sie alle meine früheren Tutorials auf meiner Profilseite. Fühlen Sie sich frei, meinem auf meinem Blog zu folgen oder mir auf Twitter zu folgen, wo ich häufig über beide spreche.

Ressourcen

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.