Willkommen zu einem neuen Eintrag der Serie „Design Patterns in der Praxis“. Für den Heutigen Eintrag habe ich mir das „Registry Pattern“ vorgenommen.

Das Registry Pattern (zu dem ich schockierender weise keinen Wikipedia Artikel finden konnte) wird, wie der Name schon sagt, idealerweise als „Registry“ (bzw. „Register“) genutzt. Nun, „Register“ kann eine Menge bedeuten – stellt euch einfach eine Konfiguration vor in welcher verschiedene Einstellungen gespeichert sind.

Wie fein ihr diese Einstellungen granuliert ist natürlich eure Sache. Solltet ihr ein CMS (Content Management System) basteln würde sich z.B. anbieten alle Basis-Einstellungen in einem solchen Register-Objekt zu speichern damit ihr überall auf eure Einstellungen zugreifen könnt. Ja, richtig, ihr könnt von überall aus darauf zugreifen!

Das Registry Pattern ist eine reine statische Klasse – Das bedeutet es wird nie mit einer Instanz des Objekts gearbeitet sondern nur mit deren gespeicherten Werten – Diese werden über Getter und Setter hinzugefügt und abgerufen.

Und damit ihr euch mal genauer Vorstellen könnt was ich genau meine habe ich hier einen kleinen Quellcode-Ausschnitt.

// Relativ am Anfang unserer Applikation machen wir folgende Einstellungen bekannt...
Register::set('base_url', $_SERVER['DOCUMENT_ROOT'] . DIRECTORY_SEPARATOR);

$database = array(
    'host' => 'localhost',
    'db' => 'datenbank_name',
    'login' => 'login_name',
    'passwort' => 'password'
);
Register::set('database', $database);

// Wir können an jeder beliebigen Stelle im Code auf die gespeicherten Werte zugreifen!
$asset = Register::get('base_url') . 'images/bild.jpg';

Es macht durchaus Sinn für verschiedene Situationen verschiedene Register zu nutzen – Bevor wir nun aber ‚zig Register Klassen in unserem Quellcode rumfliegen haben benutzen wir lieber eigene kleine Namespaces 🙂

// Kein "echter" Namespace, aber durch diesen Trick sparen wir Resourcen.
Register::set('core.base_url', $url);
Register::set('core.logged_in', false);

// ...
Register::set('db.host', 'localhost');
Register::set('db.database', 'datenbank');

// ...
Register::set('login.user_id', $_SESSION['user_id']);

Ich denke ihr versteht in welche Richtung es geht. Solche selbst definierten Namespaces (in diesem Sinne) sind häufig sehr nützlich und machen sicherlich sehr viel mehr Sinn als einfach alles blind in den Register zu pusten…

Ein eigenes Namensschema solltet ihr möglichst immer verwenden, egal ob es nun um Namen von Datenbank-Tabellen, Namespaces oder Klassen geht!

Und natürlich gibt es auch Heute wieder einen fertigen Design-Pattern Code für euch!

// Registry Pattern
class Register
{
    /**
     * In diesem statischen Daten-Array werden alle Daten abgelegt.
     * @var  array
     */
    static private $data = array();

    /**
     * Diese Methode liefert den gewünschten Datensatz zurück.
     * Wird kein Schlüssel übergeben, werden alle Daten zurück geliefert.
     *
     * @param   string  $key
     * @return  mixed
     */
    static public function get($key = null)
    {
        if ($key === null)
        {
            return self::$data;
        }

        if (isset(self::$data[$key]))
        {
            return self::$data[$key];
        }

        return null;
    }

    /**
     * Öffentliche Methode zum setzen von Werten.
     * 
     * @param  string  $key
     * @param  mixed   $value
     */
    static public function set($key, $value)
    {
        self::$data[$key] = $value;
    }
}

Eine kompakte Klasse, die aber ihren Sinn wunderbar erfüllt! Falls ihr auf Nummer sicher gehen wollt, könnt ihr in der set() Methode noch prüfen ob es sich beim übergebenen Schlüssel um einen String oder einen Numerisch Wert handelt (Objekte und Arrays gehören hier nicht rein!). Der zu speichernde Inhalt allerdings kann so ziemlich alles sein – Von Strings, über Integer, Floats, Arrays und Objekte ist alles erlaubt!

Optional könntet ihr noch eine Methode zum löschen der Daten einbauen oder eine Methode die nur Daten eines bestimmten Namespaces löscht (also alle Inhalte die als Schlüssel Beispielsweise db.* oder core.* besitzen).

Auch eine Cache Funktion, welche das Daten-Array serialisiert und in einer Datei ablegt, macht sicherlich in einigen Situationen Sinn! Passt aber auf, keine sensiblen Informationen (wie z.B. Datenbank-Login oder Benutzerpasswörter im Klartext) im Cache zu speichern – Das stellt eine Sicherheitslücke dar!

Wie bei den anderen Design-Patterns müsst ihr aber unbedingt aufpassen dieses Konstrukt nicht für alles zu missbrauchen was ihr „eventuell“ noch mal im Code brauchen könntet. Soll heißen: Speichert wirklich nur globale Einstellungen, die ihr öfters braucht und nicht etwa Daten-Schnipsel die ihr „nur kurz Zwischenspeichern“ wollt.

Echte Vor- und Nachteile zu diesem Pattern kann ich leider keine Liefern – Es kommt zu sehr darauf an, wie ihr mit der Klasse arbeitet!

In diesem Sinne wünsche ich euch noch eine angenehme Woche und freue mich euch nächste Woche wieder begrüßen zu dürfen! Happy Coding 🙂