Rapid Prototyping: Vom Prototyp zum Code, Teil 2

Last updated 4. November 2022

Inhalt

Jetzt sind wir organisiert (mit einer Ausnahme)

Der vorherige Beitrag zeigt viel Arbeit darin, etwas zu nehmen, das einst ein schneller Prototyp war, und diesen Prototyp in Code zu überführen. Wenn Sie nicht mitverfolgt haben, haben wir Folgendes getan:

gesprochen und einen Prototyp für ein Plugin gebaut,
wie skizziert, kann ein objektorientierter Ansatz funktionieren,
und unseren Prototypen in den tatsächlichen Code umgestaltet.

An diesem Punkt gibt es noch ein paar Dinge, die wir tun können, um unseren Code zu verbessern. Wir können nämlich das Konzept der Namespaces einführen. Dies bringt die Organisation einen Schritt weiter und kann sich für größere Projekte auszahlen.

Hier ist ein Blick darauf, wie sich das in unserem aktuellen Projekt auswirkt.

Prototyp zum Coden: Namespaces

Ich habe Namespaces in früheren Beiträgen ausführlich behandelt. Wenn Sie es nicht gelesen haben, empfehle ich es. Dann komm zurück und schau dir den Rest des Beitrags an.

Wenn Sie den Artikel überspringen möchten, finden Sie hier eine kurze Definition eines Namensraums :

Namespaces sollen zwei Probleme lösen, auf die Autoren von Bibliotheken und Anwendungen stoßen, wenn sie wiederverwendbare Codeelemente wie Klassen oder Funktionen erstellen…

Und die allgemeine Idee ist, dass wir unsere Klassen auf der Grundlage einer logischen Beziehung organisieren, die sie zueinander haben.

Darüber hinaus organisieren wir die Dateien auch in Verzeichnissen, die dem Namensraum entsprechen. Dies ist nicht unbedingt erforderlich, aber ich finde, dass es hilfreich ist, die Klassen auf der Festplatte logisch so zu organisieren, wie sie virtuell im Namensraum organisiert sind.

Nachdem dies gesagt ist, lassen Sie uns die Dateien organisieren.

Organisieren der Dateien

Anstatt mit der Haupt-Plugin-Datei zu beginnen, beginnen wir damit, zuerst unsere Dateien zu organisieren.

Die Dateien Meta Box und Meta Box Display befinden sich in einem Verzeichnis namens Display. Das ist völlig willkürlich, aber da diese Dateien das tun, scheint es sinnvoll zu sein, dass sie sich dort befinden.
Wir können auch die Dateien message-description.php und no-post-list.php in diesem Verzeichnis ablegen, aber legen wir sie in einem Unterverzeichnis namens Views ab. Sie können dies Templates oder Partials oder ähnlich nennen.
Als nächstes haben wir die Klassen, die für die Abfrage der Datenbank verantwortlich sind, und die Klasse, die für die Koordinierung der Nachrichtenübermittlung verantwortlich ist. Lassen Sie uns jedes davon in Utility platzieren. Natürlich gibt es andere Orte, an die sie gehen könnten, aber denken Sie daran, dass der Zweck darin besteht, zu demonstrieren, wie Namespaces verwendet werden. Wenn Sie also Lust dazu haben, können Sie Ihre Dateien nach Ihren Wünschen anpassen.

Wenn Sie dem gefolgt sind, was wir oben beschrieben haben, sollten Sie eine Verzeichnisstruktur haben, die ungefähr so aussieht:

Eine Möglichkeit, Ihre Dateien zu organisieren.

Jetzt ist es an der Zeit, Namespaces für jede der Klassen zu definieren. Da wir sie alle in ihren Verzeichnissen organisiert haben, ist es einfach, einen Namensraum anzugeben; Es ist jedoch wichtig zu erkennen, dass wir das Schlüsselwort use verwenden müssen, wenn wir Klassen verwenden, die sich in anderen Namespaces befinden.

Lassen Sie uns jede unserer Dateien durchgehen, beginnend mit den Dateien in Utility. Zuerst beginnen wir mit dem Post Messenger :

Sie werden feststellen, dass der Namespace der Datei im Header zusammen mit einer Deklaration zur Verwendung der von uns erstellten Post Query -Klasse angezeigt wird. Ich habe den Namen der Klasse an das Ende des Namespace angehängt, sodass ich ihn nicht in der gesamten Codebasis verwenden muss.

Beachten Sie, dass der Konstruktor jetzt so aussieht :

Ich habe ein $plugin_dir- Argument hinzugefügt, weil wir dieses verwenden müssen, um die Ergebnisse der Abfrage richtig anzuzeigen. Und da sie sich jetzt in einem anderen Bereich der Anwendung befinden, sehen die Funktionen so aus :

Sehen wir uns als Nächstes die Post Query -Klasse an. In dieser Klasse hat sich nicht viel geändert, außer dass wir ihr einen Namensraum gegeben haben und wir haben auch die Abfrage aktualisiert, nur um drei Posts zurückzuziehen (gemäß diesem Kommentar ).

Beachten Sie im Code, dass ich WP_Query auch einen Schrägstrich vorangestellt habe, da es Teil des globalen Namespace ist.

Lassen Sie uns in das Display – Verzeichnis wechseln und einen Blick auf die Klasse Meta Box werfen. Diese hat auch einen Namensraum erhalten und verwendet auch den vollständig qualifizierten Namen der Klasse Meta Box Display, die wir uns gleich ansehen werden.

Beachten Sie, dass dieser Konstruktor auch das Plugin-Verzeichnis als Argument akzeptiert und es auch an die Klasse Meta Box Display übergibt. Dies dient dazu, dass die für die Anzeige der Meldungen verantwortlichen Funktionen ordnungsgemäß an ihrem Ort im Views- Verzeichnis gefunden werden können.

Lassen Sie uns abschließend noch einmal die Meta Box Display -Klasse überprüfen . Dies ist eine einfache Klasse, die den Namespace enthält und auf den Post Messenger verweist, den wir oben überprüft haben.

An diesem Punkt haben wir den Kreis durch das Plugin geschlossen. Mit einer Ausnahme: Die Bootstrap-Datei. Wir haben ihm einen Namensraum hinzugefügt und müssen die Art und Weise aktualisieren, wie er instanziiert wird :

Wir haben nämlich:

den Namensraum definiert,
auf den Speicherort der Meta Box -Klasse verweisen,
Die Pfade wurden aktualisiert, um den Speicherort der Dateien aufzunehmen (was letztendlich mit einem Autoloader erledigt werden kann).
und den Aufruf add_action aktualisiert .

Hier ist die Sache mit dem Aktionsaufruf add: Da WordPress diese Funktion lokalisieren muss und die Funktion in einem Namensraum liegt, muss der vollständig qualifizierte Name der Funktion identifiziert werden, damit WordPress sie aufrufen kann. Daher die Notwendigkeit für NAMESPACE im Namen der Funktion.

Jetzt sind wir organisiert (mit einer Ausnahme)

Wie Sie sehen können, fügen Namespaces und Verzeichnisse, die mit ihnen übereinstimmen, einem Projekt viel Organisation hinzu. Es ist einfacher zu verfolgen und zu verstehen, wohin die Dinge gehen (sowohl für vorhandene als auch für neue Dateien). Und es gibt weniger das Gefühl, nur viele Dateien an einem einzigen Ort anzuhäufen.

Auch wenn eine Klasse ein bisschen wie ein Monolith aussieht, kann sie dennoch so organisiert werden, dass die Wartung einfach ist.

Abgesehen davon würde ich noch etwas an diesem Plugin ändern: Das Herumreichen des Verzeichnisses des Plugins auf diese Weise ist nicht etwas, das bei geringer Kohäsion hilft, und es koppelt die Klassen enger zusammen, da die Bootstrap-Datei einen Wert übergeben muss in eine Klasse, die es an eine andere Klasse übergibt, die es zum Laden von Dateien usw. verwendet.

Gibt es also Möglichkeiten, dies zu beheben? Unbedingt. Und vielleicht schauen wir uns das im letzten Beitrag an.

Denken Sie bis dahin daran, dass die neueste Version des Plugins im Master-Zweig mit der Kennzeichnung 0.3.0 auf GitHub verfügbar ist.

Serienbeiträge

Aufnahmequelle: tommcfarlin.com