Singletons sind...

[tfa]

Aus aktuellem Anlass mal eine kleine Umfrage zum Thema Singletons.

 

[Noctarius]

Ja ich bekenne mich schuldig, ich benutze sie hin und wieder, wenn sie aus MEINER Sicht Sinn machen.

PS: Jetzt kommen die Anderen wieder, es gibt keine Stellen wo es Sinn macht *gg*

 

[Spacerat]

"Hin und wieder" ist mir persönlich ein bissl wenig, "Oft und gerne" dagegen schon wieder zu viel. Sigleton ist eben ein Designpattern, welches wie seine ganzen Kollegen durchaus eine Existenzberechtigung hat. Z.B. bei der Entwicklung eines "Service", wie gerade aktuell: mein "JoalAudioDevice".

 

[byte]

Wenn ich Klassen habe, die ich zur Laufzeit nur einmal instanziere, dann benutze ich das Singleton Pattern nicht. Dazu sehe ich keine Veranlassung. Wenn ich nur eine Instanz einer Klasse brauche, dann erzeuge ich halt nur eine Instanz der Klasse. Kein Grund, gleich einen privaten Konstruktor einzuführen.

Ich benutze aber manchmal aus Faulheit (genau) ein Singleton (und nicht mehr) in meiner Anwendung. An dieses Singleton hänge ich dann alle Informationen, die innerhalb der gesamten Anwendung global verfügbar sein müssen.
Das aber auch nur, wenn kein DI Container zur Verfügung steht...

 

[Beni]

"Überhaupt nicht" wäre dann doch übertrieben, nur halt äusserst selten.
- Wenn mich eine Library dazu zwingt (=weil eine Library zuviele Singletons verwendet, z.B. siehe Java-Swing LookAndFeels. Es ist einfach sinnlos die LookAndFeels nicht in einer globalen Liste zu verwalten).
- Oder wenn eine Resource benötigt wird die unveränderlich ist, wie z.B. eine Map aller Icons die das Programm benutzt.

Ich würde ein Singleton allerdings niemals benutzen nur weil ein Objekt "realistisch gesehen nur einmal notwendig ist". Faulheit ist keine Ausrede für Singletons.

 

[maki]

lol @ tfa

 

[Spacerat]

Versteh' ich grad' das Pattern nicht? An Singleton stellt sich doch nicht die Frage, ob ich nur eine Instanz einer Klasse brauche, sondern nur die Anforderung, das davon anwendungsweit nur ein Instanz existieren darf. Was hat das mit Faulheit zu tun?

 

[Ebenius]

Mir fehlt hier eigentlich der Haken "ein Design-Pattern mit Daseinsberechtigung, welches meist falsch und von mir nur selten verwendet wird" Aus dem Grund hab ich für 2. gestimmt.

Nachtrag: Ich schließe mich also Beni an. Und ich dachte schon, ich bin der einzige der das so sieht. *phew*

Ebenius

 

[tfa]

Mir fehlt hier eigentlich der Haken "ein Design-Pattern mit Daseinsberechtigung, welches meist falsch und von mir nur selten verwendet wird" Aus dem Grund hab ich für 2. gestimmt.

Das wollte ich bei Punkt 2 eigentlich auch noch dazu reinschreiben. Aber jede Umfrage-Option darf höchstens 100 Zeichen lang sein.

 

[Beni]

Versteh' ich grad' das Pattern nicht? An Singleton stellt sich doch nicht die Frage, ob ich nur eine Instanz einer Klasse brauche, sondern nur die Anforderung, das davon anwendungsweit nur ein Instanz existieren darf. Was hat das mit Faulheit zu tun?

In der Theorie liegst du richtig. Aber in der Praxis sieht man halt leider oft etwas anderes. Ich verweise nocheinmal auf LookAndFeels: es wäre durchaus möglich gewesen, dass jede JComponent ihre LAF vom parent erbt, und man das LAF des Root-Windows halt selbst setzen muss. Wurde nicht so gemacht weil es natürlich einfacher ist...
[highlight=java]UIManager.getColor...[/highlight]
...zu schreiben als...
[highlight=java]if( parent != null ){
LookAndFeel feel = parent.getLaF();
if( feel != null ){
feel.getColor...
}
}[/highlight]

(ok, das war etwas böse gesagt. LaF's sind etwas komplizierter, mein Punkt ist trotzdem nicht falsch :bae: )

 

[Spacerat]

In der Theorie liegst du richtig. Aber in der Praxis sieht man halt leider oft etwas anderes. Ich verweise nocheinmal auf LookAndFeels: es wäre durchaus möglich gewesen, dass jede JComponent ihre LAF vom parent erbt, und man das LAF des Root-Windows halt selbst setzen muss. Wurde nicht so gemacht weil es natürlich einfacher ist...
[highlight=java]UIManager.getColor...[/highlight]
...zu schreiben als...
[highlight=java]if( parent != null ){
LookAndFeel feel = parent.getLaF();
if( feel != null ){
feel.getColor...
}
}[/highlight]

(ok, das war etwas böse gesagt. LaF's sind etwas komplizierter, mein Punkt ist trotzdem nicht falsch :bae: )

... und nicht zuletzt, weil diese LAFs etwas komplizierter sind, ist doch "UIManager" durchaus sinnvoll. Letztendlich tauscht du in deinem Beispiel Eifer (Gegenteil von Faulheit?) gegen Performance ein ("getColor()"-Rekursiv).

 

[Spacerat]

Mal was anderes: Gibt's da 'nen Bug im Board?
Situation:
-In der Tabelle der Themen wird eine Umfrage als "ungelesen" markiert, auch wenn kein neuer Beitrag existiert. Möglicherweise hat sich also nur das Ergebnis geändert.
-Wenn ich mir den Beitrag dann ansehe ist in der Tat das Ergebnis verändert. Auffällig dabei: der Wert für den man selbst gestimmt hat wurde um eins erhöht.
-Dann wechselt man wieder in die Tabelle: Umfrage erscheint als "gelesen"
-nach einem Aktualisieren der Seite, ist es wieder "ungelesen".
So ein Bug würde das Ergebnis extrem verfälschen.

 

[L-ectron-X]

Kein Bug sondern Zufall, denke ich.

 

[didjitalist]

ich finde zwar nicht, dass singleton ein anti pattern ist, allerdings hab ich es bislang noch nie benötigt. und die fälle, in denen ich bislang singletons gesehen habe, hätten problemlos durch nen haufen statischer methoden ersetzt werden können.

hab nichts gegen das pattern, aber es ist meiner ansicht nach irgendwie überflüssig.

 

[GilbertGrape]

Mal was anderes: Gibt's da 'nen Bug im Board?
Situation:
-In der Tabelle der Themen wird eine Umfrage als "ungelesen" markiert, auch wenn kein neuer Beitrag existiert. Möglicherweise hat sich also nur das Ergebnis geändert.
-Wenn ich mir den Beitrag dann ansehe ist in der Tat das Ergebnis verändert. Auffällig dabei: der Wert für den man selbst gestimmt hat wurde um eins erhöht.
-Dann wechselt man wieder in die Tabelle: Umfrage erscheint als "gelesen"
-nach einem Aktualisieren der Seite, ist es wieder "ungelesen".
So ein Bug würde das Ergebnis extrem verfälschen.

Das hab ich schonmal im Verbesserungs-Thread gesagt. Der Thread bekommt immer ein neuen Editierungszeitpunkt, wenn jemand abgestimmt hat. Ich glaube, dass ausgerechnet der Wert erhöht wurde, für den du gestimmt hast, ist Zufall!

 

[Beni]

... und nicht zuletzt, weil diese LAFs etwas komplizierter sind, ist doch "UIManager" durchaus sinnvoll. Letztendlich tauscht du in deinem Beispiel Eifer (Gegenteil von Faulheit?) gegen Performance ein ("getColor()"-Rekursiv).

Dazu möchte ich 2 Dinge sagen.

Erstens. Dein Argument ist ein "praktisches Argument", meines ein "theoretisches Argument". Je nachdem was für Ziele man hat muss man eines stärker als das andere gewichten. Wenn wir über gutes Softwaredesign sprechen wollen, befinden wir uns auf der Ebene der (grauen?) Theorie.

Zweitens. Ich hab auch schon eine Library geschrieben die etwas ähnliches wie LAFs anbietet, aber dort auf das Singleton verzichtet. Was ich davon gelernt habe: es ist möglich, es ist nicht so schwierig wie man vielleicht befürchtet, die Performance geht nicht merklich zurück; es wäre auch für LAFs möglich.

[Edit: und langsam benötige ich ein anderes Beispiel, wird etwas einseitig...]

 

[byte]

Wenn wir über gutes Softwaredesign sprechen wollen, befinden wir uns auf der Ebene der (grauen?) Theorie.

Das sehe ich anders. OO-Design soll praktische Probleme lösen, z.B. die Wartbarkeit oder Qualität (Testbarkeit) der Software erhöhen. Wenn man keine praktischen Ziele verfolgt, könnte man sich das Thema schenken. Niemand zahlt Geld für die Lösung von Problemen, die bloß in der blanken Theorie existieren aber keinen praktischen Bezug haben.

 

[Ebenius]

Niemand zahlt Geld für die Lösung von Problemen, die bloß in der blanken Theorie existieren aber keinen praktischen Bezug haben.

Juchu, dann können wir ja die Hälfte aller Universitätsmitglieder entlassen?

Hab nen Clown gefrühstückt. Schmeckte komisch.

 

[byte]

Auch Forschungsprojekte an Unis haben idR einen wirtschaftlichen Hintergrund. Irgendwo müssen die Forschungsgelder ja herkommen. Die Wirtschaftlichkeit wird da nur auf einen größeren Zeitraum angesetzt.

 

[tfa]

Was wohl nicht gilt für "Laberfächer" wie Philosophie, Astrophysik, Kosmologie, Altertumsforschung etc.
Sagen wir, niemand zahlt freiwillig Geld für Lösungen von Problemen, die nur in der Theorie existieren. Der Steuerzahler wird's richten.

 

[Ebenius]

Mein Orakel informiert mich gerade, dass in diesem Thema gleich über die Wirtschaftlichkeit der Untersuchungen eines pfeifenden und malenden Orang-Utans diskutiert wird. Ich glaub mein Schwein pfeift. Schon wieder der Frühstücksclown. Der ist schuld.

Ebenius

 

[thE_29]

Ich nutze das Singleton Pattern als PoolConnection Objekt!

Da brauche ich im Konstruktor einmal die Settings einlesen und erzeuge/reservie dann die Verbindungen. Es greifen 20 verschiedene Klassen drauf zu.
Also warum sollten die alle dieses PoolConnection Objekt neu instanzieren wenns nicht nötig ist?!

Oder wie würdet ihr das lösen, wenn euch das Pattern nicht gefällt?

 

[tfa]

Oder wie würdet ihr das lösen, wenn euch das Pattern nicht gefällt?

Mit Spring über Dependency Injection das Pool-Objekt in alle 20 Klassen, in denen es gebraucht wird, injizieren. Ganz einfach und leicht zu modifizieren.

 

[mikachu]

Es kommt IMO ganz drauf an, ob sich der Singleton irgendwas "merken" soll oder nicht.
Wenn ja, dann ist es gerechtfertigt, wenn aber nicht, dann setze ich nur statische Methoden ein.

Das ist wie gesagt sehr szenario-abhängig und so allgemein kann man da IMO keine zu 100% zutreffende Auswertung geben.

Die Auswahl bei der Umfrage ist auch ziemlich grob strukturiert, wie es einige Vorposter (*gg*) schon zu Wort gebracht haben. Eine feinere Granularität wäre da angebracht, würde aber auch abschrecken ;-).

Ab und an nutze ich Singletons... wie gesagt.

 

[Developer_X]

ich finde es erfreulich, wenn ich einen Button anklicke, und dann eine geräusch höre, ich find das eigentlich ganz toll,,,
außerdem wirkt das programm finde ich besser, und professioneller

 

[maki]

Es kommt IMO ganz drauf an, ob sich der Singleton irgendwas "merken" soll oder nicht.
Wenn ja, dann ist es gerechtfertigt, wenn aber nicht, dann setze ich nur statische Methoden ein.

Naja, das reicht noch nicht.
Ein Singleton hat immer einen Zustand ("etwas merken"), sonst wäre es keines
Aber es gibt mehr Alternativen als "Singleton oder. statische Methoden".

 

[mikachu]

Naja, ich habe auch schon Quellcodes gesehen, wo auch ein Singleton verwendet wurde, welcher aber keine Zustände hatte ;-).
Eben von jemandem, der Hardcore-Singleton-User ist *gg*

Aber mal ne freche Frage: was gibt es da noch für Alternativen!?

 

[maki]

Naja, ich habe auch schon Quellcodes gesehen, wo auch ein Singleton verwendet wurde, welcher aber keine Zustände hatte ;-).
Eben von jemandem, der Hardcore-Singleton-User ist *gg*

Nun, das ist wirklich sinnfrei

Aber mal ne freche Frage: was gibt es da noch für Alternativen!?

Die Objekte die eine Referenz auf das ehem. Singleton brauchen bekommen eben eine, per Setterparameter, oder per Konstruktorparameter, oder eben nur als Methodenparameter.
Sehr einfach zu bewerkstelligen mit DI Frameworks (Spring, Guice, ja sogar EJB3 bietet diese Möglichkeit).
Hat eben den Vorteil dass man entscheiden kann (zB. fürs Testen) was verwendet werden soll, denn mit GoF Singletons ist das nicht mehr möglich, da diese "festverdrahtet" sind.

 

[tfa]

Ein Singleton hat immer einen Zustand ("etwas merken"), sonst wäre es keines

Wo steht das schon wieder?
Ein Kühlschrank am Südpol ist Blödsinn, aber trotzdem ein Kühlschrank.

 

[mikachu]

Argh, da ist wieder das Wort "Frameworks"... damit hab ich mir noch nicht näher mit beschäftigt... wird aber langsam mal Zeit, wie ich das so sehe ;-).

Vielen Dank! *mit oder ohne Ironie???*

 

[maki]

Wo steht das schon wieder?
Ein Kühlschrank am Südpol ist Blödsinn, aber trotzdem ein Kühlschrank.

Schon klar, aber wer Singletons ohne Zustand baut, frisst kleine Kinder, ääääääääähh.... hat keine Ausrede welche zu verwenden

 

[SebiB90]

Mit Spring über Dependency Injection das Pool-Objekt in alle 20 Klassen, in denen es gebraucht wird, injizieren. Ganz einfach und leicht zu modifizieren.

Was ist aber wenn es ein nicht so großes Programm ist und der Einsatz von Spring für das Projekt total übertrieben wäre?

 

[Wildcard]

Was ist aber wenn es ein nicht so großes Programm ist und der Einsatz von Spring für das Projekt total übertrieben wäre?

Was ist, wenn ein Teil deiner Applikation mal in einem größeren Framework verwendet werden soll?
Man vergisst gerne, Singletons in Java gibt es nicht, da statisch nur pro Classloader Hierarchie einzigartig ist. Da Container mit getrennten Classloadern Hierarchien aber immer wichtiger werden (OSGi, Application Server,...), funktioniert das mit dem Singleton nicht mehr.
Wenn man ein Singleton also als Pattern und nicht als Anti-Pattern verwendet hat (sprich: nicht 'es gibt nur eine Instanz', sondern 'es darf nur eine Instanz geben'), dann ist der geschriebene Code schon alleine dadurch unflexibel, das er in größeren Anwendungen nicht mehr richtig funktioniert.
Ich zitiere mal Wiki, denn da steckt viel wahres drin:

Das korrekte Design von Singletons ist schwierig – in der Regel schwieriger als Designs ohne Singletons.

 

[byte]

Was ist aber wenn es ein nicht so großes Programm ist und der Einsatz von Spring für das Projekt total übertrieben wäre?

Spring Core ist ein 280 kB kleines Jar-File. Das würde ich in jedem Projekt integrieren. :bahnhof:

 

[SlaterB]

Man vergisst gerne, Singletons in Java gibt es nicht, da statisch nur pro Classloader Hierarchie einzigartig ist.

gilt sowas übrigens auch für Enums? dann hätte man ja ganz andere Probleme oder sollen alle Enum-Mengen per Spring übergeben werden?

 

[byte]

Es gibt in Spring keine Singletons nach Definition der GOF.

 

[SlaterB]

hmm, da du vor mir als letzter geantwortet hast, muss sich das ja auf meinen Beitrag beziehen,

sind Enums auch Singletons oder was meinst du?

 

[Noctarius]

Enums sind Bunches of Singletons

 

[SebiB90]

Spring Core ist ein 280 kB kleines Jar-File. Das würde ich in jedem Projekt integrieren. :bahnhof:

Hm..ok...kenn mich mit Spring noch kaum aus und weiß nicht welche Jars für welche Funktionen gebraucht werden. Mein bisheriger Kontakt mit Spring beschränkt sich auf 3 Wochen Praktikum, in denen ich an einem Projekt gearbeitet hab, wo es eingesetzt wurde. Selbst habe ich mit Spring nichts gemacht, nur es versucht zu verstehen (wusste vorher nichtmal das etwas wie DI gibt). Und in dem Projekt wurden mit Spring eigentlich nur die Remote-Beans in ein Singleton im Client reingepackt und über das Singleton wurde dann auf diese zugegriffen. Und ich frag mich wie ihr überall die DI macht, da dann ja auch alle Models der GUI mit Spring erstellt werden müssten. Ich weiß, es wäre viel arbeit, aber ich fände es cool, wenn jemand mal ein kleines / mittelgroßes Projekt mit Spring (und vllt anderen Interessanten Sachen) entwickelt und das Schritt für Schritt im Blog erklärt

 

[Spacerat]

Enums sind Bunches of Singletons

... Öhm... nö!

public enum Type {
A, B, C, D
}

sind 4 Instanzen (A, B, C, D) der Klasse Type!

 

[thE_29]

@tfa: Was ist, wenn das aber keine WebApp ist sondern eine Standalone die mehere Verbindungen braucht? Soll ich da jetzt das SpringFramework reingeben?

Außerdem was ist wenn ich es im gleichen Programm in verschiedenen Klassen brauche? Dann kann ich entweder jeder Klasse eine Instanz der Hauptklasse mitübergeben oder irgendwo was static machen.
Oder was empfehlt ihr bei diesem Problem?

 

[maki]

@tfa: Was ist, wenn das aber keine WebApp ist sondern eine Standalone die mehere Verbindungen braucht? Soll ich da jetzt das SpringFramework reingeben?

Spring braucht keine WebApp, geht immer .

Außerdem was ist wenn ich es im gleichen Programm in verschiedenen Klassen brauche? Dann kann ich entweder jeder Klasse eine Instanz der Hauptklasse mitübergeben oder irgendwo was static machen.
Oder was empfehlt ihr bei diesem Problem?

Wieder kann Spring (oder ein anderes DI Framework) verwendet werden.

Der DI Teil von Spring ist leicht zu erlernen und spart dazu noch Code.

 

[byte]

Da brauche ich im Konstruktor einmal die Settings einlesen und erzeuge/reservie dann die Verbindungen. Es greifen 20 verschiedene Klassen drauf zu.
Also warum sollten die alle dieses PoolConnection Objekt neu instanzieren wenns nicht nötig ist?!

Oder wie würdet ihr das lösen, wenn euch das Pattern nicht gefällt?

Das ist doch genau die Sache, über die wir die ganze Zeit sprechen. Du hast eine Klasse, die Du zur Laufzeit einmal instanzierst und an verschiedenen Stellen im Code auf diese Instanz zugreifen musst.

Du benutzt nun das Singleton Pattern, um Dir das Übergeben der Referenzen auf dieses Objekt zu sparen. Das ist aber aus diversen schon angesprochenen Gründen schlecht.

Statt an x Stellen im Code ConnectionPool.getInstance().blablub() aufzurufen, solltest Du beim Initialisieren der Objekte jedem Objekt explizit eine Referenz auf den ConnectionPool geben.

Wie maki schon sagte, nehmen Dir Dependancy Injection Frameworks wie Spring da viel Arbeit ab.

 

[tfa]

Richtig. Spring ist in normalen Anwendungen auch sinnvoll. Gerade ein ("Singleton"-)Objekt in verschiedenen Klassen gebraucht wird, spart man sich durch DI viel Schreibkram. Vielleicht blogge ich mal ein Bespiel, wenn ich Zeit finde.

 

[SlaterB]

also an der Schreibarbeit kann man nun glaube ich am wenigsten sparen, wenn ich mich recht erinnere ,
neben der externen XML-Konfiguration brauch doch jede fragliche Klasse ein Klassenattribut + setter + getter,

wie soll das mit Singleton mehr werden, da könnte man ja auch ein Attribut + getter mit Lazy-Abfrage der statischen getInstance() schreiben,
spart den setter und kann dann im Code wie bei Spring
> getPool().blablub()
schreiben und nicht unbedingt
> ConnectionPool.getInstance().blablub()
falls nicht gewünscht (an manchen Stellen allerdings vielleicht doch 'kürzer' als Attribut + getter, man hätte die Wahl)

soviel nur zur Schreibarbeit, soll sonst keine Unterstützung des Singletons sein, und berücksichtigt nicht den Aufwand für Umbau für Tests oder so

 

[maki]

SlaterB,

getter braucht man in so einem Fall keine, ein setter reicht, und der macht nix weiter als den Parameter dem Attribut zuweisen.

public void setWhatever(final Whatever whatever) {
this.whatever = whatever);
}

Der setter ersetzt die Aufrufe

> getPool().blablub()
bzw.
> ConnectionPool.getInstance().blablub()

vollständig, denn danach nutzt einfach jede Klasse die whatever braucht es direkt:
whatever.doSomething();

Der XML Code, also die Spring config besteht für so einen einfachen Fall (Singleton ersetzen) zum Grösstenteil aus der Schema referenz.

Nebenbei bekommt man auch ein besseres Design der Anwendung, denn nun ist diese Abhängigkeit nicht mehr implizit, sondern explizit.

 

[tfa]

Du brauchst pro Singleton und verwendeter Klasse eine Zeile XML (okay, XML ist Mist, aber eine Zeile!), der Form

[HIGHLIGHT="xml"]<bean id="nameDerBean" class="klasse.der.bean" />[/HIGHLIGHT]

Getter und Setter brauchst du nicht, wenn du mit Annotationen arbeitest (Getter sowieso nicht):

[HIGHLIGHT="Java"]@Autowired
private KlasseDerBean meineBean;[/HIGHLIGHT]
Fertig.

Wenn du später beispielsweise doch eine andere Implementierung willst, oder für Unittests ein Mock-Objekt haben möchtest, was machst du dann bei statischen, festverdrahteten Singletons? Ist das vielleicht doch mehr Schreibarbeit?

 

[maki]

>> Getter und Setter brauchst du nicht, wenn du mit Annotationen arbeitest:

auch wieder richtig..

 

[SlaterB]

> Wenn du später beispielsweise doch eine andere Implementierung willst, oder für Unittests ein Mock-Objekt haben möchtest, was machst du dann bei statischen, festverdrahteten Singletons? Ist das vielleicht doch mehr Schreibarbeit?

hehe, hab ich doch extra vorsorglich dazugeschrieben, mehr kann man doch nicht erwarten oder?

ok, ohne setter/ getter, ist mir neu,
hätte ich für derart strukturierte Programmierung nicht gedacht, aber mag sein

 

[tfa]

hehe, hab ich doch extra vorsorglich dazugeschrieben, mehr kann man doch nicht erwarten oder?

Stimmt. Hab ich übersehen. :rtfm: