Erzeugungsmuster

Singleton

Manche Ressourcen soll es im Prozess nur einmal geben: ein Verbindungs-Pool, ein Konfigurations-Objekt, eine Registry. Singleton löst das, indem die Klasse ihre eigene Instanziierung übernimmt — der Konstruktor ist privat, eine statische Methode gibt beim ersten Aufruf die eine Instanz zurück und danach immer dieselbe.

Struktur

Drei Zutaten: privater Konstruktor (niemand kann von außen new rufen), ein statisches Feld für die Instanz, eine statische Zugriffsmethode.

final class Konfiguration
{
    private static ?self $instanz = null;

    private function __construct(private readonly array $werte) {}

    public static function getInstance(): self
    {
        return self::$instanz ??= new self(parse_ini_file('app.ini'));
    }
}

In Sprachen mit echter Nebenläufigkeit gehört das Erzeugen abgesichert (in Java etwa über ein statisches Holder-Feld oder ein Enum), sonst bauen zwei Threads gleichzeitig je eine „einzige" Instanz.

Praxisnotiz

Singleton ist das Muster, das ich in Reviews am häufigsten finde und am seltensten stehenlasse. Der Grund ist nicht die Instanzzahl — die ist meistens sachlich richtig —, sondern der zweite Effekt: Der globale Zugriffspunkt macht die Abhängigkeit unsichtbar. Eine Klasse, die intern Konfiguration::getInstance() ruft, sagt in ihrer Signatur nicht, dass sie Konfiguration braucht. Im Test lässt sie sich nicht isolieren, im Umbau nicht verschieben, und wer das System liest, sieht die Kopplung nicht.

Fast immer ist die bessere Antwort: Die Instanz bleibt einmalig, aber der Zugriff läuft über Dependency Injection. Ein DI-Container verwaltet Lebenszyklen ohnehin — „genau eine Instanz" ist dort eine Konfigurationsentscheidung statt einer Eigenschaft der Klasse. Die Klasse bekommt das Objekt im Konstruktor und ist wieder ehrlich über das, was sie braucht.

Der zweite wiederkehrende Fund: Singletons, die Zustand halten. Ein schreibbarer, prozessweit sichtbarer Zustand ist eine globale Variable mit besserer Presse. Wenn Tests sich gegenseitig beeinflussen oder erst in einer bestimmten Reihenfolge grün werden, ist das oft die Ursache.

Wann es nicht passt

Wenn die Einmaligkeit nur eine Vermutung ist. Sobald mehrere Mandanten, mehrere Datenbanken oder ein zweiter Kontext dazukommen, wird aus „genau eine" ein Umbau.
Wenn ein Container zur Verfügung steht. Dann ist Singleton doppelte Verwaltung.
Als Abkürzung, um irgendwo an ein Objekt zu kommen. Das ist der eigentliche Grund, aus dem Singletons entstehen — und der schlechteste.

Alle Design-Patterns