Singletons in WordPress, Revisited (Eine Zeit und ein Ort?)

Last updated 6. August 2022

Inhalt

Verwenden Sie immer noch Singletons in WordPress?

Bevor ich einen Beitrag über die Verwendung von Singletons in WordPress beginne (oder besser gesagt das Singleton-Muster ), möchte ich sicherstellen, dass Sie die folgenden zwei Artikel lesen:

Diese beiden Artikel bieten eine immens wertvolle Perspektive auf dieses Muster und die Gefahren seiner Verwendung, wann immer wir es während unserer Arbeit in WordPress verwenden; Bedeutet das jedoch, dass wir sie vollständig vermeiden sollten?

Ich glaube nicht.

Andererseits erkenne ich auch, dass die Artikel nicht sagen, sie vollständig zu vermeiden. Sie geben starke Argumente für ihre Verwendung und die Gefahren ihrer Verwendung, falls Sie sich dafür entscheiden sollten.

Und obwohl ich sie in der Vergangenheit definitiv benutzt habe, habe ich im Allgemeinen aufgehört. Ich bin jedoch kürzlich auf einen Anwendungsfall für ein Projekt gestoßen, in dem ich es für akzeptabel halte.

Verwenden Sie immer noch Singletons in WordPress?

Um zu begründen, warum ich dieses spezielle Muster überhaupt in Betracht ziehe, lohnt es sich meiner Meinung nach, zunächst den Anwendungsfall zu verstehen. Einfach gesagt:

Es gibt eine Verwaltungsseite, auf der der Benutzer auswählen kann, wie er die Daten auf dem Front-End der Website anzeigen möchte.
Wenn der Benutzer die Option speichert, schreibt er das PHP-basierte Format für das Datum in eine Tabelle in WordPress.
Beim Rendern eines Datums wird der Wert aus der Datenbank abgerufen und auf das zu rendernde Datum angewendet.

Und für diejenigen, die neugierig sind, gibt es nur eine Handvoll – sagen wir vier oder fünf – Möglichkeiten, wie wir dem Benutzer erlauben, das Datum anzuzeigen.

Da dieses spezielle Projekt es Benutzern ermöglicht, CSVs von Daten (einschließlich Datumsangaben) zu importieren und Daten aus den CSVs zu rendern, wenn auch in einem anderen Format, ist es erwähnenswert, dass im Back-End eine beträchtliche Menge an Datumsformatierungen stattfindet.

Da stellt sich natürlich eine Frage:

Warum formatieren Sie nicht einfach das Datum, wenn der Benutzer seine CSV-Datei importiert?

Und das liegt daran, dass der Benutzer entscheiden kann, wie das Datum gerendert wird, nachdem die CSV-Datei importiert wurde.

Abgesehen davon gibt es diesen ganzen anderen Mechanismus im Plugin, der für die Validierung, Bereinigung und das Schreiben von Benutzereingaben in die Datenbank verantwortlich ist.

Aber wenn es an der Zeit ist, Werte aus der Datenbank zu holen, insbesondere wenn es in Form des Lesens eines Werts aus einer Datenbanktabelle geschieht, und dies an mehreren Stellen in der Anwendung, wäre es nicht sinnvoll, einen einzigen Punkt von zu haben woraus sich der Wert ableiten lässt?

Ein Überblick darüber, wie dies funktioniert.

Oder anders ausgedrückt, ist es nicht sinnvoll, eine Stelle in der Anwendung zu ändern, die sich leicht durch den Rest der Anwendung kaskadieren lässt, anstatt nach allen möglichen Stellen zu suchen von:

Lesen der Option,
Stellen Sie sicher, dass es eingestellt ist,
Definieren eines Standardwerts, wenn er nicht festgelegt ist,
und Rückgabe des Wertes?

Und hier sehe ich eine gültige Verwendung eines Singletons in WordPress ins Spiel kommen: Eine Möglichkeit, Daten an mehreren Stellen in der Anwendung zu lesen. Dies bringt jedoch einige Implikationen mit sich:

die Klasse muss nicht mehr als einmal instanziiert werden (ich meine, das ist die ganze Idee des Singletons),
es wird nicht mit veränderlichen Daten zu tun haben,
es wird keine Informationen schreiben oder Informationen manipulieren.

Mit anderen Worten, es ist allein verantwortlich für das Abrufen und Zurücksenden von Informationen. Das ist es. Nichts anderes.

Eine beispielhafte Implementierung

Wie könnte das also aussehen? Hier ist eine grobe Implementierung zum Zweck der Konversation:

<?php

class Date_Formatter {

    private static $instance;

    private function __construct() {
    }

    private static function get_instance() {

        if (null === self::$instance) {
            self::$instance = new self;
        }

        return self::$instance;
    }

    public static function get() {

        self::get_instance();

        $default_format = 'm/d/Y';
        $format = get_option( 'yhd_directory_importer', false );
        if (false === $format) {
            return $default_format;
        }

        $format = $format['date'];
        $format = (isset( $format) && isset( $format['format']) )? $format['format']: $default_format;

        return $format;
    }
}

Wie Sie sehen können, erfüllt es alle oben genannten Punkte. Das heißt, es liest Daten, legt einen Standardwert fest und gibt ihn dann zurück.

Diese Klasse tut nichts anderes, als einen ganz bestimmten Datensatz zu lesen und zurückzugeben.

Ein Vorbehalt zum Caching

Da diese Klasse Daten aus der Datenbank liest, können sie natürlich zwischengespeichert werden – und sollten es möglicherweise auch sein. Der Punkt dieses Beitrags ist jedoch nicht, sich mit Transienten, Ablaufzeiten und dem Durcharbeiten all dieser Nuancen zu befassen.

Stattdessen geht es darum zu bewerten, ob dies ein gültiger Anwendungsfall für die Implementierung eines Singletons in WordPress ist oder nicht.

Warte, es muss nicht so sein!

Ich weiß, ich weiß. Psycho! Ich glaube, das ist die richtige Terminologie, aber lassen Sie uns das professionell beibehalten.

Bis zu diesem Punkt hat der ganze Beitrag darüber gesprochen, warum Sie die Verwendung von Singletons in WordPress untersuchen sollten, damit Sie Informationen mithilfe konsequent objektorientierter Prinzipien einfach abrufen können.

Aber ich denke immer noch nicht, dass die Verwendung eines Singletons in WordPress hier notwendig ist. Zumindest denke ich, dass eine statische Funktion in Ordnung ist. Und der einzige Grund, warum ich denke, dass das in Ordnung ist, ist, dass das Erstellen einer Instanz der Klasse jedes Mal, wenn Sie auf eine Funktion zugreifen müssen, die Daten abruft, die sich innerhalb der Klasse nicht ändern, übertrieben ist.

Wie sieht das also aus ?

<?php

class Date_Formatter {

    public static function get() {

        $default_format = 'm/d/Y';

        $format = get_option( 'yhd_directory_importer', false );
        if (false === $format) {
            return $default_format;
        }

        $format = $format['date'];
        $format = (isset( $format) && isset( $format['format']) )? $format['format']: $default_format;

        return $format;
    }
}

Und das ist meiner Meinung nach eine bessere Lösung als die Implementierung eines willkürlichen Entwurfsmusters, wenn es überhaupt nicht benötigt wird.

Aber ich lasse mich gerne vom Gegenteil überzeugen.

Gedanken von erfahreneren Entwicklern?

Ich habe von einem Freund und Kollegen gehört, dass die einfache Verwendung einer Namespace-Funktion sogar der richtige Weg sein könnte. Offensichtlich gibt es verschiedene Möglichkeiten, dies zu bewältigen.

Und damit bin ich daran interessiert, von den anderen zu hören, wie Sie dies noch weiter umgestalten können. Ich beschäftige mich nicht so sehr mit der Implementierung der Get -Funktion, da sie hauptsächlich für die Demo zusammengestellt wurde.

Stattdessen interessiere ich mich für Möglichkeiten, dies außerhalb des hier Dargestellten zu handhaben. Oder besser gesagt, nur Ihre Meinung zu dem, was Sie sehen.

Aufnahmequelle: tommcfarlin.com