Dieses Singleton-Pattern hat den Vorteil, dass man es sich merken kann und damit beim Thema Design-Patterns dabei ist.
Interessant ist höchstens die Frage der Initialisierung („lazy“ oder „eager“) und vielleicht noch die Frage der Abhängigkeiten, wenn man sehr viele Singletons hat.
Aber ich möchte hier einmal auf zwei Verallgemeinerungen eingehen.
Ein Singleton ist „einmal“ „im ganzen Programm“ vorhanden. Verallgemeinerungen können also bei dem „einmal“ oder bei dem Universum (hier „im ganzen Programm“) ansetzen.
Das „einmal“ auf eine bestimmte endliche Anzahl zu erweitern ist für viele Routine. Bei den Java-Entwicklern nennt sich das enum, aber in anderen Programmiersprachen gibt es oft ähnliche Konstrukte oder man kann sie sich leicht selber aufbauen, indem man die Erzeugung bestimmter Objekte einschränkt und nur für die endlich vielen „enum-Einträge“ Instanzen anlegt und entsprechend erreichbar macht.
Die andere, etwas komplexere Verallgemeinerung setzt bei dem „Universum“ an. Eine Applikation kann verteilt sein oder mehrere parallele Prozesse (nicht nur Threads) verwenden, womit man ein potentiell größeres Universum als beim klassischen Singleton hat. Frameworks kennen so etwas oft und es sind dort Komponenten oder „Beans“ mit „Application-Scope“. Entsprechend gbit es kleinere Universen, zum Beispiel „Session Scope“.
Wenn man also nur diese Komponenten richtig als Verallgemeinerungen des Singleton-Patterns liest, werden diese obskuren Frameworks vielleicht etwas verständlicher und nützlicher. Und die Investion, mal mit diesem einfachen Design-Pattern anzufangen, hat sich gelohnt. Irgendwann werden wir sehen, ob sich noch andere Patterns lohnen… 😉
Schreibe einen Kommentar