Ich hätte nie gedacht, dass ich mit meinem letzten Artikel zum Threadsicheres Initialisieren eines Singleton soviel Emotion wecken würde. Daher will ich diesen Artikel nützen, die Emotionen zusammenzufassen.

Ein kleines Missverständnis

Ziel meines Artikels war es nicht, die Verwendung der Singleton Pattern in Mulithreading Programmen zu promoten. Ziel meines Artikel war es, verschiedene Techniken vorzustellen, wie sich eine von Threads geteilte Variable auf verschiedenste Arten threadsicher initialisieren lässt. Daher ist das Singleton Pattern nur ein klassisches Beispiel für die wichtige Anforderung,  die insbesondere für lesend verwendete Variablen gilt. Denn, wer den Zugriff auf eine geteilte Variable permanent lockt, obwohl diese nur sicher initialisiert werden muss, besitzt ein großes Optimierungspotential in seinem Programm.

Da ich mich als Programmierer geoutet habe, der bewusst das Singleton Pattern einsetzt, hat mich natürlich bei dem kräftigen Gegenwind interessiert, wie weit dies sehr bekannte Muster im Einsatz ist. Aus diesem Grund habe ich eine einfache Umfrage auf Twitter gestartet. Benutzt du das Singleton Pattern? 

Die Umfrage

Für ein Tag war es möglich, seine Stimme in Form eines einfache ja oder nein abzugeben. Unter https://twitter.com/rainer_grimm/status/699717467770392576 lässt sich die Diskussion erahnen, die ich auf diversen sozialen Medien führte.

C150 Teilnehmer beteiligten sich an der Umfrage, die für einen Tag freigeschalten war.  59% gaben an, dass sie das Singleton Pattern verwenden.

Die Meinungen

Die Meinungen, die ich zu dem Singleton Pattern erhalten habe, lassen sich in zwei Antworten zusammenfassen.

1. Verwende nicht das Singleton Pattern. Das Singleton Pattern ist ein Anti Pattern.
2. Ich verwende nur bewußt das Singleteon Pattern.

Natürlich waren die Antworten deutlich wort- und facettenreicher. So stellte die Dagegen-Fraktion Dependencie Injection als die Alternative vor, die das Singleton Pattern überflüssig macht. Auch führt diese Fraktion an, das selbst die GOF das Singleton Pattern aus ihrem Buch Design Patterns. Elements of Reusable Object-Oriented Software am liebsten entfernen wollen.

Ich denke aber, eine Fraktion hat sich in dieser Diskussion nicht zu Wort gemeldet. Das ist die Fraktion der Entwickler, die das Singleton Pattern häufig verwenden. Diese Fraktion kenne ich aus meiner täglichen Arbeit. Rechne ich diese stille Fraktion in das Umfrageergebnis mit ein, so gehe ich davon aus, das ca. 80% der Entwickler das Singleton Pattern einsetzen.

Meine Meinung

Ich weiß natürlich, dass das Singleton das am kontroversesten diskutierte Design Pattern der GOF ist. Ich will mir aber nicht die Antwort so einfach machen und behaupten, das Singleton Pattern sollte häufig oder nie eingesetzt werden. Wieso ich bewusst das Singleton Pattern einsetze, will ich in zwei Punkten begründen.

1. Ich setze das Singleton Pattern ein, wenn ich versuche, eine Entität der Realität, die es nur einmal gibt, in Software zu modellieren. So habe ich vor kurzem in einer sehr mächtigen Workflow Maschine in Python einen globalen Zeitgeber benötigt, der mir hilft, die Arbeitsschritte aller Aufgaben richtig zu synchronisieren. Daher war es für mich naheliegend, den universalen Zeitgeber durch ein Singleton zu modellieren. Somit erreiche ich ein sehr schöne Übereinstimmung zwischen der Programmabstraktion und dem natürlichen Welt. Diese Übereinstimmung hilft mir enorm, meine Abstraktion besser zu verstehen und vor allem zu erklären.
2. Klar sind Singletons globale Variablen in Verkleidung. Und globale Variablen sind böse. Das ist aber zu kurz argumentiert. Globale Variablen sind böse, wenn sie veränderlich sind. Sind sie unveränderlich, können sie beliebig geteilt werden und sind implizit threadsicher. Natürlich lässt sich auf einfach über sie argumentieren, da sie immer den gleichen Wert besitzen. Damit will ich nicht für die Verwendung von unveränderlichen, globalen Variablen argumentieren. Ich argumentiere nur dafür, dass unveränderliche globale Variablen viel ihres Schreckens verlieren. Sie verschmutzen natürlich den globalen Namensraum. Ein globales Registrierungsobjekt, das als Singleton implementiert ist und zur Compilezeit initialisert wird, halte ich für eine legitime Designentscheidung.

Wie geht's weiter?

Wie's mit dem Artikel weiter geht, weiß ich nicht. Falls ich noch interessante Kommentare erhalte, werde ich diese in diesen Artikel einpflegen. Ich habe das Gefühl, dass uns das Singleton Pattern noch länger begleiten wird.

Im nächsten Artikel geht es weiter mit threadlokalen Daten.

Go to Leanpub/cpplibrary "What every professional C++ programmer should know about the C++ standard library".   Hole dir dein E-Book. Unterstütze meinen Blog.