Singleton - In diesem Fall sinnvoll?

[X5-599]

hallo,

ich habe schon desöfteren gehört, dass das singleton pattern nicht verwendet werden sollte weil es meist nicht notwendig sei.
ich habe ein spezielles problem in dem (wie ich finde) so ein design sinnvoll wäre. da ich mich aber gerne an standarts bzw. akzeptierte vorgehensweisen halte, hätte ich gerne gewusst, ob es hier eine bessere lösung gibt.

zum problem:
ich habe eine klasse, die ein commandline programm bedient und so die informationen holt, die in einer gui dargestellt werden. diese klasse würde ich nun als singleton implementieren.

begründung:
die gui soll direkt beim ersten start mit den generierten daten gefüllt werden. also brauche ich schon hier eine instanz dieser spezielle arbeiter klasse. aber auch die verschiedenen listener-klassen brauchen eine um neue daten zu generieren.
da ich zwei listener-klassen habe und halt beim ersten start daten generiert werden, brauche ich an drei stellen eine solche instanz.

ich befürchte eine übergabe per konstruktor führt zu einem noch grösseren durcheinander als es ohnehin schon ist.( meine erste gui mit MVC pattern... )

also, wie würdet ihr hier entscheiden? singleton. sinnvoll oder nicht?

gruß,
michael

 

[maki]

ich befürchte eine übergabe per konstruktor führt zu einem noch grösseren durcheinander als es ohnehin schon ist.

Das glaube ich nicht
Probier es doch mal aus.

also, wie würdet ihr hier entscheiden? singleton. sinnvoll oder nicht?

Singleton als globale Variable = "schlechte" Nutzung
Singleton um zu verhindern dass es mehr als eine Instanz einer Klasse gibt = prinzipiell richtige Nutzung, aber nicht umsetzbar in Java, da Klassen u.a. durch den Classloader eindeutig sind in einer VM, selbst wenn es ginge, wie oft braucht man diesen Fall? Lohnt es sich dafür ein sog. "syntaktisches" Singelton zu erstellen? Eher nein. -> Singleton ist meistens nutzlos

Mit der richtigen Verwendung von static oder dependency Injection braucht man es nicht.

 

[byte]

Meine Meinung: Maximal ein Singleton pro Anwendung.

 

[Wildcard]

Wie maki beschreibt ist es definitiv kein Singleton.
Oft möchten Entwickler ein Singleton haben nur um leicht auf ein Objekt zugreifen zu können. In einem solchen Fall würde es genauso eine Klasse mit nur statischen Methoden tun.
Will man den weg nicht gehen, wegen Vererbung, evtl. späteres Refactoring wenn man dann doch 'echte' Objekte braucht, oder weil man Angst vor static hat, dann gibt es einen in meinen Augen erträglichen Kompromiss.
Das Klasse erhält eine statische Methode getDefault die eine Instanz zurückliefert und versucht gar nicht erst sich durch private Konstruktoren und getInstance als Singleton auszugeben.
Auch solche Konstrukte müssen mit großer Vorsicht verwendet werden, da man Flexibilität verliert, aber an bestimmten Stellen kann das schon Sinn machen und ist sauberer als Singleton-Abuse.

 

[SlaterB]

etwas private zu machen, und der Name einer statischen Methode machen den Unterschied zwischen einem akzeptablen Konzept und einem zu verurteilenden Abuse?

die Diskussion war ja schon immer äußerst fragwürdig, aber so deutlich habe ich das hier bisher noch nicht gelesen..


wenn man einen Konstruktor privat macht, handelt man schlecht,
das muss man sich aufschreiben

 

[Wildcard]

etwas private zu machen, und der Name einer statischen Methode machen den Unterschied zwischen einem akzeptablen Konzept und einem zu verurteilenden Abuse?

Der Ansatz ist wenigstens ehrlich und unterliegt nicht den Einschränkungen eines Pseudo-Singletons. Im Prinzip handelt es sich nur um ein vorkonfiguriertes Objekt das man von zentraler Stelle abholen kann, wenn man keine spezielle Variante davon benötigt.
Vergleichbar mit suns Toolkit Klasse, die ebenfalls kein Singleton ist.

 

[KSG9|sebastian]

Wuha..man könnt wohl 1000 Seiten finden mit Antipatterns für Singletons, über Singletons die keine sind, über Singletons die keine sein sollten, über Singletons die nicht single sind.

In den allermeisten Fällen macht ein Singleton einfach keinen Sinn. Zum einen ist es enorm schwer (und vor allem performancefressend) wenn man ein Singleton zu 100% garantieren will, sofern es sich nicht via

class SingletonIrgendwas{
   private static final SingletonIrgendwas instance = new SingletonIrgendwas();
}

erzeugt wird. Deshalb sollte mans ich zuerst mal die Frage stellen ob ein Singleton an der Stelle wirklich nützlich ist.

Und für den genannten Fall würde ich kein Singleton nehmen, wozu denn? Im Endeffekt umgehst du das Antipattern mit ner "public static" Methode/Variable. Dafür ein Singleton zu nehmen sieht im Code auf den ersten Blick schöner aus, machts aber kein Stück besser.

 

[SlaterB]

das Singleton IST (im einfachen Falle) die public static Methode oder Variable, wie kann man das nur ständig falsch verstehen?

die Frage besteht bei derartigen Threads immer aus genau zwei Punkten:
1. ein Objekt soll nicht unnötig doppelt erzeugt werden (nur DAS kostet Performance und das will man vermeiden, wie soll man auf anderen Wege 'performancefressend' sein?)
2. das Objekt soll nicht als Parameter herumgereicht werden

wie kann man diese beiden Dinge umsetzen? statische Variable und fertig,
ist man bis hierhin schon ein böser Mensch? X5-599 fragt sogar extra nach, ob man sich das erlauben kann

--------------------------------
[2000 Leerzeilen eingefügt]

erst wenn man an dieser Stelle, die bisher noch überhaupt nix mit Singleton zu tun hat, einen Schritt weiter denkt und einen Begriff dafür sucht, landet man zwangsläufig bei Singleton:
frei nach Wikipedia zitiert:
"Es verhindert, dass von einer Klasse mehr als ein Objekt erzeugt werden kann. Dieses Einzelstück ist darüber hinaus üblicherweise global verfügbar."
oh, genau die beiden Punkte, um die es hier geht, na den Begriff will ich mal nicht aus meinen Gedächtnis streichen

obwohl man eigentlich gar nicht das böse Singleton und dessen abgrundtief schlimme Verwendungen goto^3 kennt,
benutzt man es doch hier in der Nähe des einfachen und zumindest nicht total ausgeschlossen Konzeptes 'statische Variable'

und schon steht die Welt am Abgrund, immer wieder lustig

statische Variabe oder Methode? naja, was solls, macht Java ja auch ab und zu,
aber wehe mit einem ganz bestimmten Namen und Konstruktor private,

und performancefressend ist es auf einmal, wodurch eigentlich, durch den private Konstruktor oder den umbenannten Methodennamen?
und man solle ein Antipattern umgehen, uiui, die dunkle Seite der Macht ist stark..

ich muss da wie immer Partei ergreifen, sorry

 

[Wildcard]

Gegen statisch ist erstmal nichts zu sagen. Ein wichtiges und nützliches Konzept, sofern richtig eingesetzt.
Patterns bestehen nicht nur aus dem tatsächlichem Code. Pattern beschreiben eine Idee. Erkennt ein Entwickler ein Pattern, knüpft er daran eine bestimmte Erwartungshaltung. Kann diese Erwartungshaltung nicht erfüllt werden, dann ist das Pattern absuse und kein 'ehrlicher' Code mehr. Das gilt es strikt zu vermeiden.
Die Frage muss man sich einfach Stellen, warum der private Konstruktor, wenn es doch eigentlich nur um den Zugriff geht und eben kein Weltuntergang herbeigeführt wird, wenn es eine zweite Instanz der Klasse gibt. Nur darum geht es beim Singleton und nur mit dieser Voraussetzung sollte man Terminologie einsetzen, die gemeinhin mit dem echten Pattern Singleton in Verbindung gebracht wird.

 

[didjitalist]

hmeine erste gui mit MVC pattern...

da du MVC schon erwähnst, ist es eigentlich auch recht simpel, die verwaltung und verfügbarkeit des objekts, das den zugriff auf das kommandozeilentool steuert, sicherzustellen: irgendein controller ist dafür zuständig. und dieser controller erzeugt auch alle listener und die davon abhängigen views, die dafür notwendig sind. anders gesagt gibt es in deinem programm irgendwo einen controller, der die majorität über das tool hat und damit auch über alle views bzw. models, die mit daten aus diesem tool gefüttert werden oder daten für das tool liefern können.

dafür braucht man kein singleton und es müssen auch keine objekte irgendwohin durchgereicht werden, wenn man es nicht möchte. davon mal abgesehen, ist es aber durchaus üblich und gute praxis, objekte, die an mehreren stellen benötigt werden, schlicht und ergreifend an diese durchzureichen. wenn ein objekt exemplare von 12 anderen objekten benötigt (ungewöhnlich, aber warum nicht?), dann spricht auch absolut nichts dagegen, einen entsprechend umfangreichen konstruktor zu schreiben.

 

[SlaterB]

Nur darum geht es beim Singleton und nur mit dieser Voraussetzung sollte man Terminologie einsetzen, die gemeinhin mit dem echten Pattern Singleton in Verbindung gebracht wird.

mit dem Argument (unbedachter) falscher Terminologie kann ich leben, das macht man als Anfänger sowieso an allen Ecken und Enden,
aber direkte Konsequenzen fürs eigene Programm sehe ich nicht

dass Singleton + vielleicht Factory einen Alleinanspruch auf den private-Konstruktor haben, macht irgendwie Sinn,
gefällt mir andererseits auch nicht so ganz

 

[Wildcard]

dass Singleton + vielleicht Factory einen Alleinanspruch auf den private-Konstruktor haben, macht irgendwie Sinn,
gefällt mir andererseits auch nicht so ganz

private Konstruktoren können für viele Klassen sehr nützlich sein. Einen privaten Konstruktor zu haben, bedeutet ja nicht, keine anderen mehr zu haben.
Das ist dann nämlich wirklich ein absoluter Spezialfall (wie bei einem Singleton)

 

[KSG9|sebastian]

Ich rede von Dingen wie

class A{
   private static A instance;

   private A(){
       tuZiemlichVieleDinge();
   }
   public static final A getInstance(){
      if(instance == null){
          instance = new A();
      }
      return instance;
   }
}

Und das ist eben kein sicheres Singleton. Für kleinere Anwendungen sicher kein Problem, sobald aber die Umgebung multithreadet ist bekomme ich damit kein garantiertes Singleton mehr. Natürlich kann man synchronisieren, und genau dann fängts an Performance zu fressen.
Wie gesagt, mit Antipattern meinte ich nicht dass das Singleton-Pattern schlecht ist, allerdings sollte man wirklich hinterfragen ob man an dieser Stelle wirklich ein Singleton braucht und, falls ja, ob es schlimm wäre wenn vom Objekt mehrere Instanzen rumfahren.
Gegen statische Methoden/Attribute habe ich auch nix, sofern man sie gezielt und sauber einsetzt. Static bringt aber auch Probleme mit sich und ist oftmals nicht zu gebrauchen wenn mit Reflection oder div. Frameworks gearbeitet wird.
Zudem wird static oft dazu mißbraucht Probleme zu lesen welche aus einem schlechten Design der Anwendung resultieren.

 

[Wildcard]

[HIGHLIGHT="Java"] public static final A getInstance(){
if(instance == null){
instance = new A();
}
return instance;
}
[/HIGHLIGHT]
Das ist ja auch grob unsinnig.
Straight Forward ist immer noch am besten.

private static A instance = new A()

Oder kannst du mir ein sinnvolles Beispiel nennen, bei dem der pseudo-lazy Ansatz Vorteile bringt?
Wenn ich die Klasse eines Singletons anfasse, will ich es doch vermutlich auch benutzen, und erst dann wird bei der Straight-Forward Variante der teure Konstruktor aufgerufen.

 

[didjitalist]

lazy initialization macht sinn, wenn der konstruktor eine checked exception schmeissen soll, die der aufrufer auch mitbekommen soll. ansonsten sollte man davon lieber die finger lassen, da hast du recht.

 

[Wildcard]

lazy initialization macht sinn, wenn der konstruktor eine checked exception schmeissen soll, die der aufrufer auch mitbekommen soll.

Ok, den gestehe ich dir zu
Alles Problem die man Gott sei Dank gar nicht hat, wenn man Singletons gar nicht erst verwendet.

 

[X5-599]

ohh boy. da hab ich ja ein ganz heisses eisen angepackt...

naja, danke erstmal an alle!
tolle beiträge von euch. aber da ihr ja gemerkt habt, dass ich was programm design angeht noch ein echter neuling bin, bin ich etwas überfordert von einigen. sicherlich verständlich? egal, ich werde das morgen ein wenig genauer ausführen. jetzt geh ich erstmal schlafen. ( OT. Bones ist vorbei und die Nacht wird kurz )
bis morgen,

michael

 

[X5-599]

guten morgen,

so, nun zu meinen Gedankengängen...
es ist im Grunde genauso wie es SlaterB gesagt hat. ich hab das Singleton nur zur Sprache gebracht, weil dieses Objekt nicht mit durchgereicht werden sollte. Eine andere Ursache hat das nicht.
Eine zweite Instanz zu erstellen wär im grunde zwar nicht schlimm, wolte ich aber nicht unbedingt haben...

Und genau aus den Gründen hab ich mich an das Singleton Pattern erinnert. Oder zumindest (und jetzt kommts) was ich für das Singleton Pattern halte/hielt! Denn mittlerweile bin ich mir das nichtmehr so sicher. In der Informatiker Schule kam genau jenes, beim Thema Patterns, nur einmal (ganz kurz) zur Sprache. Und zwar so, wie hier auch schon gepostet:

class A{
   private static A instance;

   private A(){
       tuZiemlichVieleDinge();
   }
   public static final A getInstance(){
      if(instance == null){
          instance = new A();
      }
      return instance;
   }
}

DAS hielt ich (bis jetzt) für die richtige Nutzung des Singleton Patterns. Stimmt das nun, oder nicht?

Und wie gesagt, der eigentliche Gedanke war: "herankommen an das Objekt von überall aus". Ob das jetzt Abuse oder Antipattern oder sonst irgendetwas ist, weiss ich nicht. Bin aber gerne bereit diese Art der Nutzung aus meinem Kopf zu kegeln, wenn es so ist.
Ich frage halt nur, weil ich eben schon öfters gehört habe: "meist unnötig", "unschön" etc.

Ich habe es mittlerweile übrigens ohne Singleton gelöst. In etwa so wie es didjitalist sagte(nur noch etwas anders).
bitte kommentare dazu:

Da mein Controller durch die View an die diversen ActionListener gereicht wird, dachte ich mir ich reiche nicht das Arbeiterobjekt(was mal Singleton sien sollte..) neben diesem Controller mit durch bis zu den ActionListenern, sondern ich mache das Arbeiterobjekt zu einem Feld des Controllers. Und gebe diesem eine methode getArbeiterObjekt(). So kann jeder der den Controller kennt an das Arbeiterobjekt kommen.
Ich hab mich dafür entschieden, weil es:
A) leicht in meinem projekt zu realisieren war
B) ich der Meinung bin, das Arbeiterobjekt passt zugehörigkeitsmässig ganz gut in den Controller

liege ich damit möglicherweise wieder ganz falsch? was meint ihr?

Gruß,
Michael

p.s. Happy POETS day

 

[SlaterB]

so ist das natürlich viel schöner, und im Controller hast du bestimmt

public ArbeiterObjekt getArbeiterObjekt(){
if(arbeiter == null){
arbeiter = new ArbeiterObjekt ();
}
return arbeiter ;
}


quasi ein Mini-Singleton, was man nicht Singleton nennen darf, sondern nur ein 'auf bestimmte Art eingeschränktes einzigartiges Objekt' (sonst gibts Mecker ) in einem bestimmten Context,
statisch global muss es nicht sein, in einem von einem Controller abgegrenzten Bereich gehts genauso,

auf diese Weise kann man oft auch elegant Thread-Probleme umgehen, denn jeder Thread hat seinen eigenen Context,
aber das muss dich erstmal nicht interessieren

ich find's jedenfalls gut

 

[Saxony]

Hiho,

hier mal wieder mein Standardlink für jeden Singleton Thread.

Übrigens ist laut Joshua Bloch - Effective Java Item 3
ein einelementiges Enum das beste Singleton.

[HIGHLIGHT="Java"]
public enum Singleton {

INSTANCE;

public void sayHello() {

System.out.println("Hello, I'm the best Singleton ever!");
}
}
[/HIGHLIGHT]

[HIGHLIGHT="Java"]
public static void main(String[] args) {

Singleton.INSTANCE.sayHello();
}
[/HIGHLIGHT]

bye Saxony

 

[KSG9|sebastian]

guten morgen,

so, nun zu meinen Gedankengängen...
es ist im Grunde genauso wie es SlaterB gesagt hat. ich hab das Singleton nur zur Sprache gebracht, weil dieses Objekt nicht mit durchgereicht werden sollte. Eine andere Ursache hat das nicht.
Eine zweite Instanz zu erstellen wär im grunde zwar nicht schlimm, wolte ich aber nicht unbedingt haben...

Und genau aus den Gründen hab ich mich an das Singleton Pattern erinnert. Oder zumindest (und jetzt kommts) was ich für das Singleton Pattern halte/hielt! Denn mittlerweile bin ich mir das nichtmehr so sicher. In der Informatiker Schule kam genau jenes, beim Thema Patterns, nur einmal (ganz kurz) zur Sprache. Und zwar so, wie hier auch schon gepostet:



DAS hielt ich (bis jetzt) für die richtige Nutzung des Singleton Patterns. Stimmt das nun, oder nicht?

Und wie gesagt, der eigentliche Gedanke war: "herankommen an das Objekt von überall aus". Ob das jetzt Abuse oder Antipattern oder sonst irgendetwas ist, weiss ich nicht. Bin aber gerne bereit diese Art der Nutzung aus meinem Kopf zu kegeln, wenn es so ist.
Ich frage halt nur, weil ich eben schon öfters gehört habe: "meist unnötig", "unschön" etc.

Ich habe es mittlerweile übrigens ohne Singleton gelöst. In etwa so wie es didjitalist sagte(nur noch etwas anders).
bitte kommentare dazu:

Da mein Controller durch die View an die diversen ActionListener gereicht wird, dachte ich mir ich reiche nicht das Arbeiterobjekt(was mal Singleton sien sollte..) neben diesem Controller mit durch bis zu den ActionListenern, sondern ich mache das Arbeiterobjekt zu einem Feld des Controllers. Und gebe diesem eine methode getArbeiterObjekt(). So kann jeder der den Controller kennt an das Arbeiterobjekt kommen.
Ich hab mich dafür entschieden, weil es:
A) leicht in meinem projekt zu realisieren war
B) ich der Meinung bin, das Arbeiterobjekt passt zugehörigkeitsmässig ganz gut in den Controller

liege ich damit möglicherweise wieder ganz falsch? was meint ihr?

Gruß,
Michael

p.s. Happy POETS day

Mit dem geposteten Code kann es vorkommen dass das zwei Instanzen des Singletons gibt.

Eine Möglichkeit das zu verhindern ist folgende:

class Singleton{
   private static final Singleton instance = new Singleton();
   private Singleton(){}
   public static final Singleton getInstance(){  return instance; }
}

Manchmal geht das so nicht weil man z.B. Dinge in der Klasse lazy initialisieren muss.

class Singleton{
   private static Singleton instance;
   private Singleton(){}
   public static final Singleton getInstance(){
      if(instance == null){
         instance = new Singleton();
         instance.blah();
      }
      return instance;
   }
}

Durch konkurrierende Zugriffe kann es nun passieren dass die Instanz doppelt erzeugt wird.
Dass kann man so lösen:

class Singleton{
   private static final Object MUTEX = new Object();

   private static Singleton instance;
   private Singleton(){}
   public static final Singleton getInstance(){
      if(instance == null){
         synchronized(MUTEX){
            if(instance == null){
               instance = new Singleton();
               instance.blah();
            }
         }
      }
      return instance;
   }
}

Das ganze nennt man dann Double-Check-Locking. Dummerweise bekommt man damit immernoch kein 100% garantiertes Singleton hin und synchronisierung frisst ziemlich Performance im entsprechenden Umfeld weil die VM nen "Monitor" ranhängt welcher die Zugriffe überwacht.

siehe auch Can double-checked locking be fixed? - JavaWorld

Aber auf solche Probleme stößt man in "normalen" Umfeldern eher nicht.

Deshalb:

1. Nachdenken ob es wirklich ein Singleton ist
2. Nachdenken ob man ein Singleton verwendet auf Grund von "Faulheit" oder schlechtem Design
3. Wenn 1=ja und 2=nein dann ein Singleton wie Variante 1 verwenden

Im 99%-Fall ist es völlig egal ob evtl. noch ne zweite Instanz vom Obekt rumgeistert..

 

[tfa]

Das ganze nennt man dann Double-Check-Locking. Dummerweise bekommt man damit immernoch kein 100% garantiertes Singleton hin [...]

siehe auch Can double-checked locking be fixed? - JavaWorld

Dieser Artikel ist schon ziemlich alt (8 Jahre!) und die Aussage stimmt seit Java 5 nicht mehr. Siehe hier: The "Double-Checked Locking is Broken" Declaration

Nichtsdestotrotz sind Singletons natürlich mit Vorsicht zu genießen, und Synchronisierungsvermeidung durch DCL ist völlig überflüssig.

 

[X5-599]

Danke nochmal an alle. Ein Fazit(Erkenntniss) von mir:

Ich benötigte/benötigte kein wirkliches Singleton. Das deckt sich mit den Meinungen die hier geäussert wurden, bzw. mit denen die ich bei Recherchen gefunden habe. ("In den seltensten Fällen wird ein echtes Singleton gebraucht...")

Im grossen und ganzen war es nur eine Frage der Objekt Verfügbarkeit. Und dieses Problem liess sich mit einer Vorgehensweise wie von SlaterB vorgeschlagen leicht und wie ich finde elegant lösen:

so ist das natürlich viel schöner, und im Controller hast du bestimmt

public ArbeiterObjekt getArbeiterObjekt(){
if(arbeiter == null){
arbeiter = new ArbeiterObjekt ();
}
return arbeiter ;
}

Ich benutze zwar auf diese Weise immer dasselbe Objekt(und wenn aus einem mir unverständlichem Grund doch mal ein zweites erstellt werden sollte, wär es auch nicht schlimm), aber indem die ArbeiterObjekt Klasse nicht von sich aus ein Singleton ist(private Konstruktor etc.) bleibt auch die Möglichkeit offen ein weiteres separates Objekt erstellen zu können (z.B. für Feature Erweiterungen in zukünftigen Versionen)

@SlaterB
Nee, habe ich nicht. Oder besser HATTE ich nicht Bisher hatte ich den Arbeiter vorher erzeugt und per Konstruktor dem Controller mitgegeben. Aber so wie du es vorschlägst finde ich es besser, denn: Wenn der Arbeiter schon ein Feld des Controllers wird, warum sollte er dann nicht auch von diesem erzeugt werden? Also hab' ich die Logik wie von dir beschrieben umgestellt. Finde ich wie gesagt auch viel eleganter so!
Das mit den Threads hab ich nicht ganz verstanden. Aber egal, da sehe ich in naher Zukunft auch schon einen von mir neu aufgemachten Thread

Danke an alle.

Gruß,
Michael