Teil 4 – WordPress und objektorientierte Programmierung: Ein WordPress-Beispiel – Design

An dieser Stelle haben wir klar definierte Anforderungen, wie sie in Teil 3 dieser Serie beschrieben wurden (sehen Sie es hier nach, wenn Sie es verpasst haben).

Jetzt ist es an der Zeit, über das Design unseres neuen und verbesserten Plugins nachzudenken!

Wir möchten Sie daran erinnern, dass dieser Schritt einige Zeit in Anspruch nehmen kann, wenn Sie ihn an Ihren eigenen Projekten ausprobieren. Wahrscheinlich werden Sie auch beim ersten Mal nicht alles richtig machen. Die Chancen stehen gut, dass Sie ein Design entwickeln, mit der Implementierung beginnen und dann feststellen, dass Sie zurückgehen und Ihren Ansatz überdenken müssen.

Es ist die Mühe absolut wert, also nehmen Sie sich so viel Zeit wie nötig, um alles genau richtig zu machen. Ein gut strukturiertes Projekt macht es einfacher, es zu warten und zu erweitern und sogar seinen Code in anderen Projekten wiederzuverwenden, so dass es auf lange Sicht eine gute Zeitnutzung ist.

Gleich als nächstes konzentrieren wir uns auf einige wichtige Teile des Plugins und besprechen, wie wir zu unserem Design gekommen sind.

Zerlegen der Einstellungsseite

Schauen wir uns die Admin-Seite des Plugins genauer an.

Sie werden feststellen, dass es einen Titel („Einstellungen für Anmeldeversuche beschränken“), mehrere Abschnitte mit einigen Feldern und eine Schaltfläche „Optionen ändern“ am unteren Rand der Seite gibt.

Jeder Abschnitt besteht aus einem Titel, wie „Statistiken“, und einigen Feldern.

Jedes Feld hat einen Titel auf der linken Seite und den Rest seines Inhalts auf der rechten Seite. Es gibt Textfelder, Optionsfelder und Kontrollkästchen und einige davon, wie „Total Lockouts“, zeigen nur Informationen an und können vom Admin-Benutzer nicht direkt geändert werden.

Einige Felder enthalten auch eine Beschreibung, wie das Feld „Standortverbindung“, aber nicht alle.

Vor diesem Hintergrund müssen wir es in konzeptionelle Teile zerlegen, die später zu Klassen werden.

Die WordPress-Einstellungs-API ermöglicht es uns, Einstellungsseiten, Abschnitte innerhalb dieser Seiten und Felder innerhalb der Abschnitte zu registrieren:

Seiten → Abschnitte → Felder

Wir dachten, warum nicht eine weitere „Ebene“, die Elemente, hinzufügen, um unser Plugin in Zukunft leichter erweiterbar zu machen.

Seiten → Abschnitte → Felder → Elemente

Seiten und Abschnitte sind also das, was wir oben bereits erklärt haben, und Felder enthalten Elemente aller Inhaltstypen auf der rechten Seite.

Unter Berücksichtigung all dieser verschiedenen Arten von Elementen haben wir uns für eine Element-Klasse und mehrere Klassen entschieden, um sie für die Kontrollkästchen, Optionsfelder, Zahlen usw. zu erweitern, die unterschiedliche Ausgaben liefern.

Möglicherweise müssen wir in Zukunft auch weitere Seiten und Abschnitte hinzufügen. Es ist also wahrscheinlich, dass wir diese Verwaltungsseiten- und Abschnittsklassen erweitern müssen.

Dasselbe gilt für die Felder. Die Klassen für „Totale Aussperrungen“, „Aktive Aussperrungen“ usw. werden dieselbe (Eltern-)Klasse erweitern.

Hier ist ein vereinfachtes Bild, das diese Beziehungen demonstriert:

Natürlich sind nicht alle „Komponenten“ im Diagramm enthalten.

Eine solche Struktur erleichtert die Erweiterung des Plugins; Bei Bedarf können wir problemlos ein Feld, ein Element oder einen Abschnitt hinzufügen. Wir können problemlos weitere Komponenten – Felder, Elemente oder Abschnitte – hinzufügen, indem wir neue untergeordnete Klassen erstellen, ohne vorhandene Klassen ändern zu müssen.

Denken und Abstrahieren

Jetzt ist es an der Zeit, darüber nachzudenken, was die verschiedenen Komponenten unseres Plugins tun. Während der Designphase müssen wir nicht sehr ins Detail gehen, wie etwas funktioniert.

Betrachten Sie zum Beispiel alle Elemente, Tabellen, Statistiken und so ziemlich alles andere, was dem Benutzer angezeigt wird. Sie können separate Komponenten sein, die nichts gemeinsam haben, aber alle werden irgendwann eine Ausgabe liefern. Daher werden einige Funktionen für Komponenten üblich sein, die ansonsten völlig unabhängig voneinander sind. Das gilt selbstverständlich auch für unsere restlichen Komponenten.

Im obigen Bild sehen wir, wie eine UI-Schnittstelle von mehreren Klassen implementiert wird.

Beachten Sie, dass die UI-Schnittstelle durch die Klassen Statistics, Lockout Logs, Table und Element implementiert wird, die als übergeordnete Klassen bezeichnet werden. Die Klassen Radio/Number/Checkbox Element müssen die Schnittstelle nicht direkt implementieren, da sie alle Schnittstellen von ihrer übergeordneten Klasse erben. Eine untergeordnete Klasse könnte jedoch eine Methode ihrer übergeordneten Klasse überschreiben.

Da wir wissen, dass unser Plugin mit Einstellungen umgehen wird, können wir davon ausgehen, dass wir ihre Werte lesen und schreiben werden. Das heißt, in der Lage zu sein, Optionen abzurufen , festzulegen und zu entfernen .

All diese Aktionen werden in einer Klasse gebündelt. Wir werden unsere Optionen wahrscheinlich in der WordPress-Datenbank oder so ähnlich speichern. Im Moment müssen wir uns nicht darum kümmern, wie oder wo wir unsere Daten speichern.

Wir können die Abstraktion der Get/Set/Remove-Optionen im Kopf behalten, die Dinge konzeptionell vereinfachen und unser Plugin weiter entwerfen.

Haupt-Plugin-Datei

Hier stellen wir einige Informationen über das Plugin für WordPress über den Header-Kommentar bereit und führen einige Initialisierungen durch. Wir organisieren unseren Code, indem wir alles in eine kleine Klasse packen.

Abhängig davon, wie die Klassen unseres Plugins zusammenarbeiten, muss die Hauptklasse die meisten von ihnen instanziieren. Soweit wir wissen, umfasst dies Klassen, die sich auf Optionen, Verwaltungsseiten, Wiederholungen und Sperren beziehen.

Potentielle Klassen

Wir haben uns etwas Zeit genommen, um herauszufinden, welche Klassen wir brauchen werden, und am Ende haben wir eine Liste wie folgt:

• Wiederholungen
• Aussperrungen
• Kekse
• Fehlermeldungen
• E-Mail Benachrichtigungen
• Admin-Hinweise
• Tasten
• Sperrprotokolle
• Aktive/vollständige Sperren
• IP Adresse

Denken Sie daran, dass es nicht den einen „richtigen“ Weg gibt, Ihr Plugin zu strukturieren. Wie bei den meisten Dingen in der Softwareentwicklung gibt es mehrere, gleichermaßen gültige Wege, um ein Problem zu lösen.

Im Abschnitt „Allgemeines“ würden die Beziehungen zwischen unseren Klassen beispielsweise so aussehen:

Der Abschnitt „Statistiken“ sieht ungefähr so ​​aus:

Schließlich werden die „Sperrprotokolle“ den „Statistiken“ sehr ähnlich sein:

Fazit

Bisher haben wir unsere Anforderungen definiert und über ein Design für unser neues und verbessertes Plugin nachgedacht. Wir haben erklärt, wie wir zu unserer Struktur gekommen sind, und auch einige einfache Diagramme bereitgestellt, die zeigen, wie unsere Klassen miteinander in Beziehung stehen.

Klicken Sie hier, um Teil 5 unserer Serie zur objektorientierten Programmierung zu lesen

Siehe auch

• WordPress und objektorientierte Programmierung – Ein Überblick
• Teil 2 – WordPress und objektorientierte Programmierung: Ein Beispiel aus der Praxis
• Teil 3 – WordPress und objektorientierte Programmierung: Α WordPress-Beispiel – Definition des Geltungsbereichs