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]

Zitat: 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.

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

[Beni]

Zitat: 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?

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...

1
UIManager.getColor...

...zu schreiben als...

1
2
3
4
5
6
if( parent != null ){
  LookAndFeel feel = parent.getLaF();
  if( feel != null ){
    feel.getColor...
  }
}

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

[Spacerat]

Zitat: Beni

	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... 1 UIManager.getColor... ...zu schreiben als... 1 2 3 4 5 6 if( parent != null ){   LookAndFeel feel = parent.getLaF();   if( feel != null ){     feel.getColor...   } } (ok, das war etwas böse gesagt. LaF's sind etwas komplizierter, mein Punkt ist trotzdem nicht falsch )

... 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]

Zitat: 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.

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]

Zitat: Spacerat

	... 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]

Zitat: Beni

	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]

Zitat: byto

	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.