# Denkfehler Singleton



## dable (19. Mrz 2009)

Ich hab hier das Grundgerüst eines einfachen Singletons.


```
public class Singleton
{ 
  private static Singleton instance = new Singleton(); 
 
  private Singleton() 
  { 
  } 
 
  public static Singleton getInstance() 
  { 
    return instance; 
  } 
 
}
```
 
Meine Frage dazu ist: 
Die Eigenschaft instance ist ja ein Objekt der Klasse Singleton. Imho müsste dieses Objekt wieder eine Eigenschaft instance besitzen usw. Offensichtlich ist das nicht der Fall, sonst hätte man ja eine Endlosschleife. Wie kann das sein?


----------



## Noctarius (19. Mrz 2009)

Weil Sie dank static einmal in der Klasse existiert nicht in der Instanz die du erstellst

instance.getClass() hätte wieder die Instanz


----------



## maki (19. Mrz 2009)

>> Denkfehler Singleton

Sehr wahr, Singleton ist ein  Anti-Pattern.

>> Imho müsste dieses Objekt wieder eine Eigenschaft instance besitzen usw. Offensichtlich ist das nicht der Fall,

Nicht das Objekt, sondern die Klasse, weil instance static ist.


----------



## dable (19. Mrz 2009)

ok danke!
wenn die Eigenschaft nicht static wäre, hätte ich aber eine Endlosschleife, oder?


----------



## tfa (19. Mrz 2009)

Juchu! Ein Singleton-Thread!:toll:


----------



## ARadauer (19. Mrz 2009)

kurze zwischenfrage... wenn singleton so "böse" sind, warum sind dann standardmäßig alle "hippen" spring beans singletons..... ?


----------



## Noctarius (19. Mrz 2009)

ARadauer hat gesagt.:


> kurze zwischenfrage... wenn singleton so "böse" sind, warum sind dann standardmäßig alle "hippen" spring beans singletons..... ?



Hehe die Frage hab ich mir schon 5 Singleton Threads lang verkniffen ^^


----------



## tfa (19. Mrz 2009)

Welche hippen Spring-Beans sollen das denn sein?


----------



## Noctarius (19. Mrz 2009)

Alle die nicht anders deklariert sind, werden automatisch als Singleton gehandhabt

scope="prototype"


----------



## tfa (19. Mrz 2009)

Noctarius hat gesagt.:


> Alle die nicht anders deklariert sind, werden automatisch als Singleton gehandhabt
> 
> scope="prototype"



Das ist allerdings was völlig anderes, als das Singleton-Muster wie in Beitrag #1 angegeben. Das hat damit absolut nichts zu tun.


----------



## Noctarius (19. Mrz 2009)

Naja der Effekt ist ansich der Selbe. Es wird genau eine Instanz erstellt. Nur die Art und Weise wie diese Erstellung statt findet ist anders.


----------



## maki (19. Mrz 2009)

ARadauer hat gesagt.:


> kurze zwischenfrage... wenn singleton so "böse" sind, warum sind dann standardmäßig alle "hippen" spring beans singletons..... ?


Gute Frage 

Es git einen Unterschied zwischen einem "semantischem" Singleton (liefert immer dieselbe Instanz) wie Standard Spring Beans und einem syntaktischen Singleton (angeblich nur eine Instanz möglich, kein Interface möglich da statische Methoden, dadurch nicht austauschbar in tests), eben dem klassischen Singleton Krampf -> hardcodierte globale Variable .

Die statische Schnittstelle der syntaktischen Singletons sind das eigentliche Problem, dieses haben die semantischen Singletons eben nicht 



tfa hat gesagt.:


> Juchu! Ein Singleton-Thread!:toll:


LMFAO


----------



## byte (19. Mrz 2009)

Das "böse" an Singletons ist ja nicht die Tatsache, dass die Objekte nur einmal existieren dürfen, sondern der statische Zugriff auf die eine Instanz.
Spring Beans existieren per Default nur einmal, aber der statische Zugriff existiert ja nicht.


----------



## tfa (19. Mrz 2009)

Noctarius hat gesagt.:


> Naja der Effekt ist ansich der Selbe. Es wird genau eine Instanz erstellt. Nur die Art und Weise wie diese Erstellung statt findet ist anders.


Nein. Muster "Singleton" bedeutet: es ist garantiert, dass es nur ein Objekt des Typs gibt. Bei scope="singleton" ist das eben nicht der Fall. Du kannst 100 Beans definieren, alle vom selben Typ und alle mit Singleton-Scope.


----------



## Noctarius (19. Mrz 2009)

Ok mit verschiedenen Ids 

Das könnte jetzt genauso eine Grundsatzdiskussion sein, wie ob ein static constructor einmal oder einmal pro classloader ausgeführt wird


----------



## tfa (19. Mrz 2009)

Also den Zusammenhang versteh ich jetzt überhaupt nicht....


----------



## Noctarius (19. Mrz 2009)

Wenn du nicht 2 verschiedene Beans mit 2 Qualifiern machst wird IMMER das eine Bean zurückgegeben, was genau dem Effekt des Singleton entspricht.

Gestern hatten wir die Diskussion ob ein "static constructor" nur einmal pro Programm ausgeführt wird. Für Anfänger ja. Für Fortgeschrittene nein, weil einmal pro Classloader.

Wenn du also Spring benutzt und jedes Interface nur einmal an ein Bean bindest bleibt der Effekt Singleton-Pattern.


----------



## byte (19. Mrz 2009)

Noctarius hat gesagt.:


> Wenn du also Spring benutzt und jedes Interface nur einmal an ein Bean bindest bleibt der Effekt Singleton-Pattern.



Ja, und wenn ich eine Klasse Foobar schreibe und nur einmal new Foobar() aufrufe, dann habe ich auch den Effekt des Singleton-Patterns.


----------



## Noctarius (19. Mrz 2009)

byto hat gesagt.:


> Ja, und wenn ich eine Klasse Foobar schreibe und nur einmal new Foobar() aufrufe, dann habe ich auch den Effekt des Singleton-Patterns.



Nein hast du nicht, weil diese Instanz nicht global erreichbar ist ^^


----------



## tfa (19. Mrz 2009)

Noctarius hat gesagt.:


> Wenn du also Spring benutzt und jedes Interface nur einmal an ein Bean bindest bleibt der Effekt Singleton-Pattern.




Okay, ich glaub ich verstehe. Dann kann man aber auch sagen

Integer eins = new Integer(1);

sei ein Singleton. 

(Ich mag Grundsatzdiskussionen )


----------



## Noctarius (19. Mrz 2009)

Siehe oben


----------



## byte (19. Mrz 2009)

Noctarius hat gesagt.:


> Nein hast du nicht, weil diese Instanz nicht global erreichbar ist ^^



Das ist auch nicht Sinn eines Singletons, sondern nur ein Nebeneffekt bei der durch die GOF vorgeschlagenen Implementierung des Patterns.

Dein Beispiel mit den Spring Beans ist halt nicht vergleichbar. Denn der "Singleton-Effekt" bezieht sich in Spring nicht auf den Typ (also die Klasse), sondern auf die Bean-Definition. 

Man kann durchaus mehrere Spring Beans des selben Typs mit scope singleton definieren. Und das sind dann zur Laufzeit auch unterschiedliche Objekte des selben Typs. Aber es sind halt auch unterschiedliche Beans.


----------



## tfa (19. Mrz 2009)

[Haarspalterei]Darüber hinaus ist es ja nicht verboten, ein GOF-Singleton "package-protected" also nicht public zu definieren. Das wäre dann auch nicht global erreichbar, trotzdem ein Singleton.[/Haarspalterei]


----------



## Noctarius (19. Mrz 2009)

byto hat gesagt.:


> Man kann durchaus mehrere Spring Beans des selben Typs mit scope singleton definieren. Und das sind dann zur Laufzeit auch unterschiedliche Objekte des selben Typs. Aber es sind halt auch unterschiedliche Beans.



Ja klar, aber eben unter der Voraussetzung, dass sie verschiedene Qualifier besitzen 

Egal, genau Haarspalterei ^^


----------



## byte (19. Mrz 2009)

Noctarius hat gesagt.:


> Ja klar, aber eben unter der Voraussetzung, dass sie verschiedene Qualifier besitzen



Falsch. Der Qualifier hat damit gar nichts zu tun. 
Du kannst zwei Beans desselben Typs ohne Qualifier deklarieren. Spring erzeugt dann zwei Objekte dieses Typs und nicht eins.


----------



## Noctarius (19. Mrz 2009)

byto hat gesagt.:


> Falsch. Der Qualifier hat damit gar nichts zu tun.
> Du kannst zwei Beans desselben Typs ohne Qualifier deklarieren. Spring erzeugt dann zwei Objekte dieses Typs und nicht eins.



Als anonymes Bean 

Aber zweimal das selbe Interface ohne Qualifier und als nicht anonymes Bean geht nicht. Wäre schon allein technisch nicht umsetzbar mit dem @Autowired Annotation, weil es die 2 Beans nicht auseinander halten könnte


----------



## byte (19. Mrz 2009)

Noctarius hat gesagt.:


> Aber zweimal das selbe Interface ohne Qualifier und als nicht anonymes Bean geht nicht. Wäre schon allein technisch nicht umsetzbar mit dem @Autowired Annotation, weil es die 2 Beans nicht auseinander halten könnte



Der Qualifier (ID) muss per Definition eindeutig sein, richtig. Das hat aber nix mit dem Scope zu tun und noch weniger mit Singletons.  Das funktioniert genauso wenig mit scope="prototype"...


----------



## Ebenius (19. Mrz 2009)

maki hat gesagt.:


> >> Denkfehler Singleton
> 
> Sehr wahr, Singleton ist ein  Anti-Pattern.


Nein. _Singleton_ ist ein Muster und damit dem allgemeinen Problem unterworfen, dass man es nur dort einsetzen darf wo es tatsächlich Sinn ergibt. Das Hauptproblem an Mustern im allgemeinen ist, dass sie, aufgrund der Tatsache dass sie vorgefertigt existieren, schnell den Anschein erwecken, man könne sie eben mal anwenden ohne genauer darüber nachzudenken. Dann trifft man eben Entscheidungen die einer genaueren Prüfung nicht standgehalten hätten. Das passiert bei _Singleton_ leider überdurchschnittlich oft.

Wenn die Realität des Problembereichs jedoch festlegt, dass es nur eine Instanz einer Art geben kann, dann ist das Singleton-Muster genau das richtige. Beispielsweise würde ich ohne zögern für ein Gebetsprogramm der katholischen Kirche die _God_-Klasse als _Singleton_ konzipieren. Wenn diese Designgrundlage nicht mehr stimmt, dann nutzt das Programm ohnehin nichts mehr. :lol:



Noctarius hat gesagt.:


> Das könnte jetzt genauso eine Grundsatzdiskussion sein, wie ob ein static constructor einmal oder einmal pro classloader ausgeführt wird


Das Ding heißt _Initializer_, nicht _Constructor_. Ein _Constructor_ erzeugt eine Instanz einer Klasse.

Ebenius


----------



## Noctarius (19. Mrz 2009)

Ebenius hat gesagt.:


> Das Ding heißt _Initializer_, nicht _Constructor_. Ein _Constructor_ erzeugt eine Instanz einer Klasse.



Verrat doch nicht alles  Nagut du hast mich erwischt, falscher Begriff ^^


----------



## maki (19. Mrz 2009)

> Nein. Singleton ist ein Muster und damit dem allgemeinen Problem unterworfen, dass man es nur dort einsetzen darf wo es tatsächlich Sinn ergibt. Das Hauptproblem an Mustern im allgemeinen ist, dass sie, aufgrund der Tatsache dass sie vorgefertigt existieren, schnell den Anschein erwecken, man könne sie eben mal anwenden ohne genauer darüber nachzudenken. Dann trifft man eben Entscheidungen die einer genaueren Prüfung nicht standgehalten hätten. Das passiert bei Singleton leider überdurchschnittlich oft.


Sehe ich anders.
Singleton ist nicht nur ein Anti-Pattern weil es falsch eingesetzt wird (globale Variable), sondern weil es in der vorgeschlagenen Form (static getInstance und interne Abhängigkeit zu instance) auch nicht testbar ist bzw. auch Tests von davon abhängigen Klassen sehr schwierig macht (schlecht testbares Design ist kein gutes Design).
Man erinnere sich nur an das von Sun vorgschlagene DAO Pattern inkl. abstrakter und konkreter DaoFactory.

Klar kann man Singleton auch vernünftig einsetzen, zB. wenn es nur intern in einer Klasse verwendet wird und von niemandem ausserhalb, aber dann kann man auch ohne Singleton gewährleisten das nur eine Instanz erzeugt wird.


----------



## Ebenius (19. Mrz 2009)

Ich persönlich bin vorsichtig, wenn es darum geht, Muster die von Entitäten wie der Gang of Four publiziert wurden zum Anti-Pattern zu erklären. 

PS: Ich bleibe bei meinem Gott-Beispiel oben. Es wäre extrem widersinnig, einen Gott mit Einzigartigkeitsanspruch in einer Fabrik zu fertigen und noch bekloppter, diese omnipräsente Entität als Argument für das Ziel des Gebetes zu übergeben. 

Ebenius


----------



## maki (19. Mrz 2009)

Ebenius hat gesagt.:


> Ich persönlich bin vorsichtig, wenn es darum geht, Muster die von Entitäten wie der Gang of Four publiziert wurden zum Anti-Pattern zu erklären.
> 
> Ebenius


Naja, zum Glück ist das ja nicht auf meinem Mist gewachsen 

Jedenfalls muss man einsehen dass dieses Buch aus einer Zeit stammt, in der OO zwar Hip aber noch nicht ganz verstanden war und Dinge wie "Dependency Injection" und Unittesting nicht weit verbreitet waren.
Das Original verwendet  nicht die UML Notation (gab es damals noch nicht) und Beispiele wurden in C++ (würg) beschrieben.
Die anderen beschriebenen Muster sind immer noch oft verwendet und bei weitem nicht so umstritten.

Wobei es heute natürlich eine Flut von "Patterns" gibt die sich damals wohl niemand hätte träumen können...



> PS: Ich bleibe bei meinem Gott-Beispiel oben. Es wäre extrem widersinnig, einen Gott mit Einzigartigkeitsanspruch in einer Fabrik zu fertigen und noch bekloppter, diese omnipräsente Entität als Argument für das Ziel des Gebetes zu übergeben.


Naja, glaube nicht das wir beide so gläubig sind dass wir  wirklich davon ausgehen können jederzeit mit der Gott Instanz in kontakt treten zu können wenn wir wollten 
Abgesehen davon ist das "God Object" ein echtes Anti-Pattern (SCNR).


----------



## byte (19. Mrz 2009)

Kann mich maki nur anschließen.

In meinen Augen sind Singletons mehr als unnötig und verleiten bloß dazu, statische Zugriffe quer über der gesamten Anwendung zu verteilen, was im schlimmsten Fall zu zyklischen Abhängigkeiten und Deadlocks führt.

Warum zum Geier muss eine Klasse zum Singleton werden, nur weil zur Laufzeit bloß eine Instanz der Klasse existiert? Reicht es nicht einfach, nur einmal den new Operator zu benutzen?

Das Spring Framework ist ein gutes Beispiel. Da gibts viele Klassen, von denen zur Laufzeit nur eine Instanz existiert (siehe z.B. AccessDecisionManager im Spring Security Modul). Trotzdem existieren immer öffentliche Konstruktoren.


----------



## Noctarius (19. Mrz 2009)

Klar aber dann musst du irgendwo diese eine Instanz zugänglich machen, z.B. über eine rein statische Accessorklasse ApplicationContext oder wie auch immer du diese nennen willst


----------



## byte (19. Mrz 2009)

Noctarius hat gesagt.:


> Klar aber dann musst du irgendwo diese eine Instanz zugänglich machen, z.B. über eine rein statische Accessorklasse ApplicationContext oder wie auch immer du diese nennen willst



Kommt drauf an, an wievielen Stellen diese Instanz gebraucht wird. Zunächst mal gibts ja die rein objektorientierte Lösung, Objektreferenzen beim Initialisieren zu übergeben. Nichts anderes machen DI Container wie Spring. 

Händisch (also ohne DI Container) ist das natürlich etwas nervig, wenn gewissen Objekte an sehr vielen Stellen im Code gebraucht werden. In diesem Fall schreibe ich mir genau ein GOF Singleton mit statischem Zugriff und hänge alle global benötigten Objekte an dieses Singleton.


----------



## Ebenius (19. Mrz 2009)

maki, ich würde jederzeit unterschreiben, dass das Singleton-Muster [HIGHLIGHT]umstritten[/HIGHLIGHT] ist. Ganz sicher auch, dass man es [HIGHLIGHT]mit Vorsicht[/HIGHLIGHT] einsetzen sollte. Auch, dass es [HIGHLIGHT]in der Regel[/HIGHLIGHT] die falsche Wahl ist. Und dass es um Längen [HIGHLIGHT]zu häufig benutzt[/HIGHLIGHT] wird. Als Anti-Pattern ist es trotzdem nicht anerkannt.

Ebenius


----------



## Wildcard (19. Mrz 2009)

Ebenius hat gesagt.:


> PS: Ich bleibe bei meinem Gott-Beispiel oben. Es wäre extrem widersinnig, einen Gott mit Einzigartigkeitsanspruch in einer Fabrik zu fertigen und noch bekloppter, diese omnipräsente Entität als Argument für das Ziel des Gebetes zu übergeben.


Wenn der katholische Gott so omnipotent ist, wie behauptet, kann er/sie auch mehrfach existieren wenn er/sie das möchte und auch austauschbar sein und von einer Fabrik erzeugt werden (wenn eine Instanz von er/sie die Fabrik dafür erzeugt) :bae:


----------



## maki (19. Mrz 2009)

Einverstanden Ebenius, bevorzuge aber aus rein polarisierenden Gründen den Begriff "Anti-Pattern" 

Mann muss imho auch unterscheiden zwischen dem GOF Singleton und Klassen von denen eben nur eine Instanz zur Laufzeit existiert (syntaktisch vs. semantisch).
Letzteres ist häufig der Fall, deswegen muss man aber nicht mehrere GoF Singletons haben.
DI Frameworks  bieten Alternativen dafür und sogar für den "new" Operator an sich.

Klar habe ich das GoF Singleton auch mal benutzt und mittlerweile benutze ich manchmal immer noch als ein einzelnes in einer App(dann aber abgewandelt), was zwar gegen das sog. "Law of demeter" verstösst aber an machen Stellen durchaus vertretbar ist, so wie bei jeder Designentscheidung muss man halt immer abwägen.


----------



## Ebenius (19. Mrz 2009)

maki, so werden wir uns tatsächlich einig. Unglaublich.

Nach dem Schuldbekenntnis kann ich jetzt also Deine Stimme in der Umfrage ändern, oder? 

Wildcard, ich glaube Gott spricht in der Deutschen Bibel in der Einzahl von sich und hat damit seine Entscheidung getroffen. Und die Omnipräsenz verbietet, dass er erzeugt wird, weil er schon da ist. Aber die Wege des Designs sind ja ebenfalls unergründlich. Quatsch, hab gut gelacht über Deinen Beitrag.

Ebenius.getInstance()


----------



## Spacerat (19. Mrz 2009)

Was geht denn hier ab? Ich schliesse mich mal diesem hier an:





> Ich persönlich bin vorsichtig, wenn es darum geht, Muster die von Entitäten wie der Gang of Four publiziert wurden zum Anti-Pattern zu erklären.


Während Singleton hier und da einfach NOTWENDIG! (entwickelt mal einen Service ohne... viel Spass) ist, gibt es eine Unzahl an Designpatterns die wirklich überflüssig sind und teilweise möglicherweise nur deswegen existieren, weil jemand Singleton nicht verstanden hat. Obwohl... ein "God-Singleton" ist ein schlechtes Beispiel für OOP "CatholicGod" dagegen nicht.
Mit Singleton signalisieren API-Entwickler, das von einer Klasse anwendungsweit nur eine Instanz existiert.
Ich als Entwickler muss eine Klasse meiner APIs, von der anwendungsweit nur eine Instanz existieren darf, als Singleton entwickeln. Verlässt diese Klasse mein API dagegen nicht (weil z.B. packagescoped), kann ich mich dazu entschliessen diese, nicht als Singleton zu entwickeln, wenn ich nur eine davon brauche.


----------



## Ebenius (19. Mrz 2009)

Spacerat hat gesagt.:


> Obwohl... ein "God-Singleton" ist ein schlechtes Beispiel für OOP "CatholicGod" dagegen nicht.


Darüber hatte ich nachgedacht. Wenn Du allerdings meinen Beitrag genau liest und Dir dann vorstellst, in gesagter Auftragsentwicklung der katholischen Kirche (deswegen hatte ich diese gewählt) die Designentscheidung zu treffen, es gebe einen abstrakten Gott und dann einen konkreten katholischen; dann hätte ich Dich gern in den Projekt-Treffen mit dem Auftraggeber erlebt. :lol:

Ebenius


----------



## Wildcard (19. Mrz 2009)

> Während Singleton hier und da einfach NOTWENDIG! (entwickelt mal einen Service ohne... viel Spass)


Um einen OSGi Service zu erstellen/publizieren, brauche ich kein Singleton.


> Ich als Entwickler muss eine Klasse meiner APIs, von der anwendungsweit nur eine Instanz existieren darf, als Singleton entwickeln. Verlässt diese Klasse mein API dagegen nicht (weil z.B. packagescoped), kann ich mich dazu entschliessen diese, nicht als Singleton zu entwickeln, wenn ich nur eine davon brauche.


Nö. Du kannst auch einfach den Konstruktor mit default Visibility ausstatten, dafür braucht es kein Singleton.


----------



## Ebenius (19. Mrz 2009)

Wildcard hat gesagt.:


> Nö. Du kannst auch einfach den Konstruktor mit default Visibility ausstatten, dafür braucht es kein Singleton.


Meinst Du eine "getInstance()"-Methode und einen default Constructor? Oder meinst Du was anderes? Was gewinnt man jetzt dadurch?

Ebenius


----------



## Noctarius (19. Mrz 2009)

Ebenius hat gesagt.:


> ... es gebe einen abstrakten Gott und dann einen konkreten katholischen; dann hätte ich Dich gern in den Projekt-Treffen mit dem Auftraggeber erlebt. :lol:



Boah nee Ihr seid krank ^^


----------



## Ebenius (19. Mrz 2009)

Als Alternative hätte ich den _Highlander_ nehmen können. Aber so ist's lustiger. Fakt ist, das Singleton lässt sich anhand des Beispiels nicht so einfach wegdiskutieren. 

Ebenius


----------



## Wildcard (19. Mrz 2009)

Nein, keine getInstance. Wer sagt, das der Konsument einer API sich die Instanz direkt bei der Klasse abholen muss? Ob etwas real ein Singleton ist, oder nicht, sehe ich eher als Implementierungsdetails, warum muss ich diese Entscheidung in einer API nach aussen tragen? 
APIs müssen kompatibel bleiben und daher muss man noch viel viel vorsichtiger mit Singletons sein, weil du diese statische Referenzierung für den Konsument später nicht mehr transparent ändern kannst. Wenn sich aufgrund unvorhergesehener Ereignisse herausstellt, das ein Singleton keine gute Idee war, kann man es nie wieder auf kompatible Weise geradebiegen.


----------



## Ebenius (19. Mrz 2009)

Wildcard hat gesagt.:


> APIs müssen kompatibel bleiben und daher muss man noch viel viel vorsichtiger mit Singletons sein, weil du diese statische Referenzierung für den Konsument später nicht mehr transparent ändern kannst. Wenn sich aufgrund unvorhergesehener Ereignisse herausstellt, das ein Singleton keine gute Idee war, kann man es nie wieder auf kompatible Weise geradebiegen.


Diesen Teil unterschreibe ich so auch. Das ändert nichts daran, dass es eben Fälle gibt, in denen alle Kriterien gegeben sind. Es hängt nunmal immer vom Problembereich ab. In einem Kontext kann "OperatingSystem.getInstance()" legitim sein, in einem anderen nicht. Die Entscheidung lässt sich pauschal nicht treffen, in einem konkreten Problembereich jedoch schon. Aus dem Grund kann man auch nicht vom Anti-Pattern sprechen, weil dazu notwendig sein würde, dass das Pattern grundsätzlich ungültig wäre.

Ebenius


----------



## Spacerat (19. Mrz 2009)

Ebenius hat gesagt.:


> ... dann hätte ich Dich gern in den Projekt-Treffen mit dem Auftraggeber erlebt. :lol:


Ich mich auch... sagt dir der Name "Anton Szandor LaVey" etwas? Sicher... wenn man danach googelt.


----------



## Ebenius (19. Mrz 2009)

Spacerat hat gesagt.:


> sagt dir der Name "Anton Szandor LaVey" etwas? Sicher... wenn man danach googelt.


Jetzt sagt er mir was. Aber was willst Du mir sagen?

Ebenius


----------



## Wildcard (19. Mrz 2009)

Ebenius hat gesagt.:


> Das ändert nichts daran, dass es eben Fälle gibt, in denen alle Kriterien gegeben sind. Es hängt nunmal immer vom Problembereich ab. In einem Kontext kann "OperatingSystem.getInstance()" legitim sein, in einem anderen nicht. Die Entscheidung lässt sich pauschal nicht treffen, in einem konkreten Problembereich jedoch schon. Aus dem Grund kann man auch nicht vom Anti-Pattern sprechen, weil dazu notwendig sein würde, dass das Pattern grundsätzlich ungültig wäre.


Sehe ich genauso. Benutze das Pattern trotzdem nicht, weil ein echtes Singleton in Java nicht möglich ist, dann kann man es sich auch sparen.
Das Pattern als solches ist ein echtes Pattern, kein Anti-Patter, wird allerdings ständig falsch verwendet, hat sehr wenige Use-Cases und macht in Java nicht wirklich Sinn.


----------



## Spacerat (19. Mrz 2009)

@Ebenius: ... das ich eher seine (LaVeys) Ansichten, als die irgend einer Kirche teile. So ein Treffen kann deswegen lustig sein, muss (wird) es aber nicht. ...jedem das seine... sag ich mal.
@Noctarius: als "krank" würd' ich das nicht bezeichnen... einfach mal lesen... (seine Bücher mein' ich...)


----------



## Noctarius (19. Mrz 2009)

Spacerat hat gesagt.:


> @Noctarius: als "krank" würd' ich das nicht bezeichnen... einfach mal lesen...



Ich les die ganze Zeit mit und krank war auch nicht im Sinne von "gehört ins Krankhaus" gemeint sondern eher verrückt von wegen der Vergleiche im Bereich Gott (also im lustigen Sinne verrückt)


----------



## Ebenius (20. Mrz 2009)

Spacerat, es ging mir ja gar nicht um Ansichten. Nur die Vorstellung, einen abstrakten Gott vor irgendeiner Weltreligion verteidigen zu müssen... Ich glaube, sowas gehört in den Kurs "Marketing für Fortgeschrittene". 

Ebenius


----------



## byte (20. Mrz 2009)

Spacerat hat gesagt.:


> entwickelt mal einen Service ohne... viel Spass


Ich schreibe häufig Services. Keiner davon ist ein GOF Singleton. Dein Problem ist, dass Du nur den Hammer kennst. Daher siehst Du überall nur Nägel.


----------

