vielen Dank für das Feedback.

Ich habe mal einige Kritikpunkte als zusätzlichen Teil in das Kapitel eingearbeitet.

Gruß
Stefan

Mir ist durchaus bekannt, dass es ein “offizielles” Pattern der GoF ist, was aber meine Kritik nicht schmaelert.

Natuerlich koennen Sie meine Kritikpunkte in den Thread einarbeiten.

Danke

danke für den umfangreichen und informativen Kommentar.

Ich versuche erst gar nicht, die einzelnen Punkte zu entkräften oder denen entgegenzuwirken. Einfach deshalb nicht, weil Sie in den meisten Fällen recht haben.

Ein Singleton macht schlichtweg in den wenigsten Situationen Sinn (auch wenn ich nicht so weit gehen möchte und behaupten, dass ein Singleton wirklich nie sinnvoll ist). Dennoch ist es ein relativ verbreitetes Pattern, welches auch im Buch der GoF zu finden ist, weshalb es letztendlich auch den Weg in das Java Blog Buch gefunden hat.

Mit Ihrer Genehmigung würde ich Ihre Kritikpunkte gerne (leicht modifiziert) in das Kapitel einarbeiten.

Vielen Dank und Grüße
Stefan

>Aber irgendwie müssen Sie von überall (ohne, dass ein bestimmtes >Objekt vorhanden ist) auf dieses Attribut zugreifen können.
Nennt sich auch globale Variable und sind absolut zu vermeiden. Wenn eine Klasse auf etwas zugreifen muss, so soll diese als Abhaengigkeit mitgeteilt werden, nicht ueber irgendwelche magic access der Klasse selber. Das hat mehrere Probleme:

im Grunde luegt das Programm bzw die API. Es werden explizit keine Abhaengigkeiten deklariert, aber aufgrund von globalen Zugriffen hat man auf einmal einen Objektgraphen mitzukompilieren. Es werden sozusagen Abhaengigkeiten verschleiert.

untestbar: man will in seinen Tests Objekte erzeugen, testen, wegschmeissen – weiterhin will man allgemein dass ein stueck code bei wiederholten aufruf, ohne informationsfluss von aussen, immer das selbe tut… durch singletons bzw globale zustaende ist dies nicht gesichert.

Test klappt, Test klappt nicht, Test klappt, Test klappt nicht…
Man hat eine Testsuite die 1h laeuft. Der letzte Test schlaegt fehl. In Isolation geht er durch… viel Spass das zu debuggen.

Weiterhin hat man durch Singletons nicht nur eine globale Variable, da meist das Singleton selbst noch Referenzen haelt und diese wieder und diese wieder, was eben so theoretisch unendliche vielen globalen Zustaenden sich ausweitet.

>Und wie >stellen Sie sicher, dass nicht einfach ein neues Objekt der >Klasse erzeugt >wird?
In dem man einfach Objekterzeugung aus der Logik rausnimmt. Kein logikcode, keine datenklasse erzeugt irgendwelche Objekte, es wird alles per Konstruktor (bzw methoden) explizit reingegeben (stichwort Dependency Injection).
Es gibt 1 Stelle, und nur 1 Stelle an den Objekte erzeugt werdene und verdrahtet werden.

Das Singleton verletzt das SingleResponsiblity Prinzip, es ist sowohl fuer logik zustaendig, als auch sicherzustellen, dass es die Instanz nur einmal gibt. Nicht die Klasse hat das zu regeln, sondern die Applikation.

D.h. es ist nicht verwerflich von einer Klasse nur eine Instanz in seiner Applikation zu haben, es ist aber verwerflich wenn die Klasse diese Einzigartigkeit selbst erzwingt.

Summasumarum: Singletons sind nicht zu verwenden und eine Designschwaeche. In 9 von 10 Faellen wird es nicht aufgrund seiner Einzigartigkeit genommen (wofuer es bessere alternativen gibt), sondern eben genau wegen “muss ueberall zugreifen koennen” – der groesse Denk und designfehler.

unbedingt empfehlenswert: http://www.youtube.com/watch?v=-FRm3VPhseI