singleton vs. static

[Solour]

Hey,

so wie ich das sehe macht die singletonverwendung oft keinen sinn.
Eine klasse die vollständig static ist gibt es ja schließlich auch nur einmal (und das mit 100%iger sicherheit)

• gibt es außer den folgenden noch gute gründe FÜR singleton?
  [list:a7660fd3ac]
• abhängig vom classloader wird eine statische klasse evtl. geladen obwohl nicht direkt verwendet. damit sind ressourcennutzungen verbunden. sind diese nutzungen inakzeptabel macht es sinn dies zu verhinden. (z.B. beim laden von bildern etc. durch die klasse) durch singleton-verwendung kann also die ressourcennutzung auf den zeitpunkt verschoben werden zu dem sie benötigt wird. (evtl. werden die ressourcen auch garnicht verwendet, falls die klasse nicht zum einsatz kommt)
• evtl. sollen während dem programmfluss dann doch mehrere der objekte erzeugt werden. dabei stellt also die singleton-klasse sicher das nur eine gewisse zahl von objekten existieren (auch bekannt als "multiton")

[*]gibt es gute argumente GEGEN singletons? (evtl. irgendwelche spezialfälle?)
[*]warum ist java.lang.Math kein singleton(hab ich jedenfalls grad wo gelesen)?
[*] könnt ihr real-life probleme schildern wo singletons ratsam waren?
[*] ich kann mit vorstellen das man viele situationen nennen kann, wenn das objekt das singleton sein soll aus einer ableitung ensteht. gibt es für sonstige fälle gute beispiele?
[/list:u:a7660fd3ac]

bis dann
Solour

ps: ja den faq entry hab ich gelesen,
ja gesucht hab ich schon,
ja gegoogled auch ;P

pps: gibt es gute links zur dokumentation von classloadern? (interessieren mich eigenelich nur sun/blackdown in versionen 1.4.2 + 1.5)

 

[Beni]

IMHO haben Singletons gegenüber Klassen bei denen überall ein "static" hingauen wurden, folgende Vorteile:

• Man kann sie immernoch relativ leicht ersetzen durch andere Klassen
• Man kann auch Interfaces oder abstrakte Klassen als Singletons verwenden
• Innerhalb des Singletons kann man normal weiterprogrammieren, insbesondere kann man die "this"-Referenz weiterhin benutzen.

Gegen Singletons spricht dasselbe wie gegen static:

• Man kann es immer anders lösen (nicht immer einfacher :wink: )
• Man baut sich was ziemlich unflexibles ins Programm ein. Im vorraus sagen "das gibts nur einmal" - damit kann man gewaltig auf die Nase fliegen
• Eine Umstellung ist später sehr schwer, komplizierter jedenfalls als gleich zu Beginn auf Singletons zu verzichten

java.lang.Math ist so eine Spezialfall... PI wird sich nie ändern, ebensowenig wie der Sinus jemals eine andere Funktion sein wird. Math muss intern keine Variablen speichern, und die viele Methoden sind nativ implementiert. Anders gefragt: wieso sollte man ein Math-Objekt benötigen? Man benötigt nur die Methoden und Konstanten.

Real-life: ich verzichte weitgehendst auf Singletons und static's, sinnvolle Anwendungen sehe ich hier:

• Um Ressourcen zu laden, Icons, Bildchen, Plugins, ... und z.B. in einem Cache behalten
• Als Ober-Super-Kontroller-Objekt, das Ding, welches das Programm startet, und welches auch als einziges das Programm wieder schliessen kann (andere Objekte dürfen höflich nachfragen, selbst aber nichts unternehmen).
• Vielleicht auch um einen Worker-Thread zu implementieren (ein Thread der ausserhalb des EDT's Dinge berechnet).

Ich würde aber darauf verzichten, etwas Singleton zu machen, nur weil es in der "echten" Welt Singleton ist. Weil der Planet "Erde" nur einmal existiert, sollen wir nur eine Instanz von seinem Model anlegen? Dabei wäre es doch lustig verschiedene Aktionen (Meteorit schlägt ein, Sonne explodiert, Nächste Eiszeit beginnt) an verschiedenen Kopien auszuprobieren :wink:

 

[bygones]

so wie ich das sehe macht die singletonverwendung oft keinen sinn.
Eine klasse die vollständig static ist gibt es ja schließlich auch nur einmal (und das mit 100%iger sicherheit)

das würde implizieren, dass die Sicherheit bei einem Singleton nicht gegeben ist und das ist falsch !!

 

[nEp]

Also ich würde auch sagen, dass man in Java eigentlich immer um Singletons herum kommen sollte. Da gibt es eigentlich immer bessere und v.a. flexiblere Lösungen.
Wie schon weiter oben gesagt, würd ich dass auch, wenn überhaupt, für so Resourcen-Sachen verwenden.

In C++ haben Singletons IMHO schon ein kleines bisschen mehr Sinn. Man könnte z.B. eine Klasse, die direkten Zugriff auf die Tastatur bietet (z.B. bei Spielen) durchaus als Singleton implementieren, da man diese ja eh immer nur genau einmal braucht. Dadurch hätte man diese Klasse als eine art globale Variable definiert und könnte sich die ganzen "extern"-Deklarationen bei jeder neuen Datei ersparen, die diese Klasse verwendet.
Da Java hier aber anders funktioniert, entfällt dieser Case für Java.

 

[SlaterB]

Singleton-Objekte sind Objekte und keine Klassen!

das ist in manchen Fällen unumgänglich,
wie beim Casten auf Oberklassen (Rückgabetyp einer Operation) oder in der Verwendung als ActionListener/ Einfügen in eine Liste und ähnliches

kann nicht beteuern dass das überhaupt sinnvolle Einsatzzwecke für Singleton/ Klassen sind,
aber technisch geht das eben nur als Objekt

 

[Solour]

Hey,

Schonmal vielen dank für die Antworten

• Man kann sie immernoch relativ leicht ersetzen durch andere Klassen
  Naja warum kann man das nicht auch bei statischen klassen?
• Man kann auch Interfaces oder abstrakte Klassen als Singletons verwenden
  ja genau. man verbaut sich also praktische diese möglichkeit. gut.
• Innerhalb des Singletons kann man normal weiterprogrammieren, insbesondere kann man die "this"-Referenz weiterhin benutzen.
  man kann doch mit äquivalenter semantik "KlassenName." schreiben. (Mir ist der unterschied schon klar
• das würde implizieren, dass die Sicherheit bei einem Singleton nicht gegeben ist und das ist falsch !!
  das wäre korrekt, würde da nicht der konjunktiv sein . was ich meinte ist das man den singleton dann natürlich korrekt implementieren muss und das scheint mir nach recherche nicht für jeden ganz einfach..(zumindest die multithread/multiprozessor varianten)
• wie beim Casten auf Oberklassen (Rückgabetyp einer Operation) oder in der Verwendung als ActionListener/ Einfügen in eine Liste und ähnliches
  das meinte ich mit "ich kann mit vorstellen das man viele situationen nennen kann, wenn das objekt das singleton sein soll aus einer ableitung ensteht. gibt es für sonstige fälle gute beispiele?"

mir wäre zwar eine ultimative kategorisierung lieber bei der ich nicht jeweils abwägen und nachdenken müsste aber das geht wohl leider wie so oft nicht.

bis dann
Solour

 

[byte]

Ich finde die Tatsache, dass Singletons Objekte sind, schon grund genug nicht static zu arbeiten! Objekte ermöglichen Delegation, Aggregation, Vererbung, Trennung von Konzept und Implementierung (abstract, Interfaces) und so weiter und so fort. Singletons können demnach perfekt in die Objektstruktur eingegliedert werden. Ausserdem kann man sie serialisieren...

Statische Klassen hingegen machen imo nur als Util Klassen Sinn. Also Methoden, die unabhängig von einem Status oder Kontext einfach nur Funktionität bereitstellen sollen, wie z.B. die Methoden aus Math. Eine Methode zur Berechnung der Quadratwurzel beispielsweise, kann Verwendung in jedem möglichen Kontext finden. Es wäre nicht sinnvoll, extra dafür ein Objekt instanzieren zu müssen.

 

[Beni]

Noch ein paar Bemerkungen zu deinen Antworten:

Man kann sie immernoch relativ leicht ersetzen durch andere Klassen
Naja warum kann man das nicht auch bei statischen klassen?

Dann versuch mal 100 Aufrufe der Form "Blabla.machWas( ... )" im Code zu ersetzen :wink: Oder ersetzt du lieber direkt die statischen Methoden (da geht auch schnell was kaputt)? Und bevor du an ein Delegate denkst (die static-Methoden rufen einfach andere auf), da hilft dir der Compiler immernoch nicht, alles richtig umzuschreiben, oder die Implementation ist wieder ein Singleton.

Innerhalb des Singletons kann man normal weiterprogrammieren, insbesondere kann man die "this"-Referenz weiterhin benutzen.
man kann doch mit äquivalenter semantik "KlassenName." schreiben. (Mir ist der unterschied schon klar

Aber nicht für jedes Problem. Manchmal muss man ja auch einer Methode was übergeben (z.B. ein ActionListener), mit der "alles static"-Variante musst du dir da noch extra ein Objekt anlegen / speichern; beim Singleton könntest du das direkt implementieren.

mir wäre zwar eine ultimative kategorisierung lieber bei der ich nicht jeweils abwägen und nachdenken müsste aber das geht wohl leider wie so oft nicht.