Singleton-Muster
Das Singleton-Muster stellt sicher, dass eine Klasse nur eine Instanz hat und bietet einen globalen Zugriffspunkt darauf. Verwende es, wenn du genau ein Objekt zur Koordination systemweiter Aktionen benötigst – wie einen Konfigurations-Manager, Logger oder Verbindungspool.
Überblick
Das Singleton-Muster beschränkt eine Klasse auf eine einzige Instanz und stellt einen globalen Zugriffspunkt darauf bereit. Es ist eines der einfachsten kreativen Muster, aber auch eines der umstrittensten, weil es globalen Zustand in ein System einführt. Bewusst eingesetzt für Ressourcen, die wirklich nur einmal existieren sollten – ein Konfigurationsspeicher, ein Logger, ein Verbindungspool – beseitigt es den Aufwand, dieselbe Referenz überallhin weiterzureichen, und garantiert Konsistenz.
Wann verwenden
- Du brauchst genau eine Instanz einer Ressource, die in der gesamten Anwendung geteilt wird (Konfiguration, Logger, Cache).
- Die Instanz zu erstellen ist teuer, und du willst es bis zur ersten Verwendung verzögern (Lazy Initialization).
- Du willst eine einzige Quelle der Wahrheit, die Aufrufer ohne Dependency-Injection-Verkabelung erreichen können.
Beispiel
class Logger {
private static instance: Logger;
private constructor() {}
static getInstance(): Logger {
if (!Logger.instance) {
Logger.instance = new Logger();
}
return Logger.instance;
}
log(message: string) {
console.log(`[${new Date().toISOString()}] ${message}`);
}
}
Logger.getInstance().log("App gestartet");Vorteile
- Garantiert eine einzige Instanz und einen einzigen Zugriffspunkt.
- Lazy Initialization vermeidet die Kosten, bis die Instanz tatsächlich gebraucht wird.
- Ersetzt ad-hoc globale Variablen durch einen kontrollierten, gekapselten Lebenszyklus.
Nachteile
- Führt globalen Zustand ein, was Unit-Tests und Parallelität erschwert.
- Versteckt Abhängigkeiten — Aufrufer greifen ins Singleton, statt zu deklarieren, was sie brauchen.
- Kann zum Bottleneck oder Memory Leak werden, wenn die Lebensdauer dem gesamten Prozess entspricht.