Left Up Right Entwurfsmuster

Singleton

Es wird sichergestellt, daß es nur eine Instanz einer Klasse gibt

Kombination mit Multithreading

Double Checked Locking
Thread Specific Singleton
Es gibt je Thread eine Instanz, die im Thread specific Speicher abgelegt ist.

Überlegungen zur Implementierung und zum Gebrauch

Die Singletoneigenschaft sollte möglichst lose sein

Manche Leute wollen die Singleton-Eigenschaft dadurch erzwingen, in dem sie alle Attribute und Methoden statisch (C++) machen.
Sollte sich erweisen, daß die Klasse doch kein Singleton ist, oder in einem anderen Kontext wiederverwendet werden, wo das doch nicht der Fall ist, muß dann doch der Code modifiziert werden.
Schöner ist doch, wenn es nur eine Methode gibt (instance()) die das Singleton zurückliefert.
In ACE muss nur ein Template ausgeprägt werden.

Assoziationen gehen verloren

Wenn ein System aus Grobkomponenten besteht, dann könnte man jede Komponente als Singleton deklarieren und die Komponenten kennen sich dann implizit über diese Singletoneigenschaft.

Nachteil: Die Beziehungen untereinander sind nur implizit im Code enthalten. Die Assoziation, die mit einer referenz/einem Zeiger implementiert wird, ist dann beim reverse engineering nicht sichtbar.
Stattdessen ist doch ein Objekt für das Gesamtsystem sinnvoll, daß

Sinnvoll: Infrastrukturobjekte

Infrastrukturobjekte in Ablaufsystemen wie Speicherverwaltung, Errorlogging usw. sind Objekte, die auf der Implementierungsmetaebene auftreten und keinen Sinn in der Anwendeungsebene (Businessmodell) machen. So möchte jede Klasse Debugausgaben machen. Im UML-Modell hierzu Assoziationen zu modellieren, würde jeden Überblick verhindern.

Vorteil:

Mit Singleton-Muster und verschobener Initialisierung kann man Komponenten in beliebiger Reihenfolge aufstarten lassen.
Informatik- und Netzwerkverein Ravensburg e.V Rudolf Weber