Erinnerung: Singletons vermeiden

Heute mal ein Gedanke, der im Grunde keine Erläuterung braucht: Singletons werden fast nie gebraucht und sollten vermieden werden.

Auf den Google-Seiten zur Test-Coverage der Google Update Engine bin ich gerade nochmal auf einen interessanten Link gestoßen, warum Singletons eine schlechte Idee sind: The Singleton Smell, immerhin von Juli 2006, von Greg Miller auf im Unixjunky Blog.

Zusammengefaßt läßt sich sagen: Singletons sind eine Übertragung des Konzeptes globaler Variablen auf OO-Design, was allein schon verdächtig ist, und erschweren bzw. verhindern Unit Tests, da sie die Verwendung von Mock-Objekten erschweren bzw. verhindern.

Im Grunde sollte es immer möglich sein, Singletons zu vermeiden, da ja jedes Programm einen definierten Startpunkt hat, von dem aus Objekte instantiiert und Methoden aufgerufen werden. Problematisch sind wohl nur "magische" Bibliotheken, die zwar technisch initialisiert werden müssen, diese Tatsache in ihrem Interface aber verheimlichen. Mal ein ausgedachtes Beispiel: Eine Bibliothek zur Verschlüsselung benötigt einen Zufallsgenerator, der wiederum mit einem Initialisierungsvektor instantiiert wird. Im Interface der Bibliothek taucht der aber nie auf, sondern wird von der Bibliothek im Hintergrund verwendet. Wenn die Funktionen der Bibliothek jetzt keine Referenz auf eine Bibliotheksinstanz bekommen, müssen sie über ein Singleton den Zufallsgenerator finden.

Warum sollte man jetzt den Zufallsgenerator auslagern? Nun, einerseits kann mit dem versteckten Generator nicht überprüft werden, ob Verschlüsselungsroutinen auch wirklich immer funktionieren, z.B. für besondere Zufallszahlen. Man kann andererseits auch nicht prüfen, ob der Zufallsgenerator hinreichend zufällig arbeitet.

Man kann also nur noch akzeptieren, daß die Bibliothek als Ganzes funktioniert, oder eben sehr lange testen und hoffen, zufällig auf Fehler zu stoßen -- die dann aber nicht mehr reproduzierbar sind. Insgesamt unschön, und nur durch Redesign der Bibliothek korrigierbar, was wieder ein Refactoring aller Applikationen nach sich zieht, die auf der Bibliothek aufbauen. Noch unschöner, und der ausschlaggebende Grund, warum einige Bibliotheken bzw. Frameworks voraussichtlich nie "verbessert" werden.

Schlußfolgerung: Vermeiden, wo es geht, und wo es nicht geht, überlegen, ob es nicht doch geht.