Singletons

[dowhile]

***. Vor allem hab ich vor recht kurzer Zeit erst die Singletons entdeckt, das macht noch mal 'nen RIESIGEN Unterschied gegenüber dem vorherigen static-Gekrakel

Singleton-Gekrakel ist aber genau so böse wie static-Gekrakel.

[Padmak]

Was wäre dann noch besser, um z.B. einen Manager für irgendwas zu schreiben?

Padmak

[Schlüsselbein]

Was für einen Manager meinst du genau?
Wer braucht Zugriff auf diesen? Singletons sind die umstrittensten aller (Anti-)Pattern. Es wird mE viel zu häufig zwanghaft verwendet.

[MrSm!th]

Habs mal in nen eigenen Thread verschoben ;O
Was genau ist an Singletons ein Anti-Pattern? Welche bessere Option gibt es für Klassen, die nur eine Instanz erlauben?

[Schlüsselbein]

Das Anti hab ich hier in Klammern gehalten, da es wie gesagt ziemlich viel Diskussion ums Singleton gibt.

Ich bin schon der Meinung, dass es overused ist.

Welche bessere Option gibt es für Klassen, die nur eine Instanz erlauben?

Die Frage sollte sein: Wann braucht man nur eine einzige Instanz einer Klasse _und_ globalen Zugriff auf diese. Ein Logger wäre ein legitimes Beispiel.
Oft kann man durch anderes Design die enge Kopplung, die das Singleton als negativen Nebeneffekt hat, komplett umgehen.
Deswegen auch meien Frage an Padmek, was für einen Manager er meint und wie dieser verwendet werden soll.

[Padmak]

Ich hab jetzt nochmal bisschen genauer drüber nachgedacht, man kann tatsächlich oft genug die Singletons vermeiden... aber irgendwie sind die doch auch bequem, oder nicht?
Und abseits aller Bequemlichkeit, welche echten Gründe gibt es denn gegen die Nutzung der Singletons?
Eine Instanz braucht man z.B. bei einem Netzwerk-Backend, wenn man dann von überall Daten senden möchte, muss man zumindest irgendein Singleton haben.. und ob das jetzt die Netzwerkklasse oder eine andere ist, ist doch egal?

Padmak

[Schlüsselbein]

aber irgendwie sind die doch auch bequem, oder nicht?

Das Thema gibts ja oft. Bequemlichkeit über Sauberkeit und Wartbarkeit.

Und abseits aller Bequemlichkeit, welche echten Gründe gibt es denn gegen die Nutzung der Singletons?

Unit testing wird viel schwieriger und komplizierter (für Hobbyprogrammierer meistens nicht relevant) und wie gesagt ist der Code dadurch noch enger gekoppelt (was man ja meistens vermeiden will).

Eine Alternative wäre ein Interface mit einer konkreten Implementation. Normalerweise hat man ja ein Controller oder ähnliches, welcher dann die Instanz erstellt und an die Klassen via Parameter übergibt. Nennt sich Dependency Injection (Google verrät dir dazu mehr).

Edit: Hier dazu ein Text, den ich mal auf Stackoverflow fand:

Singletons are like communism: they both sound great on paper, but explode with problems in practice.

The singleton pattern places a disproportionate emphasis on the ease of accessing objects. It completely eschews context by requiring that every consumer use an AppDomain-scoped object, leaving no options for varying implementations. It embeds infrastructure knowledge in your classes (the call to GetInstance()) while adding exactly zero expressive power. It actually lessens your expressive power, because you can't change the implementation used by one class without changing it for all of them. You simply can't add one-off pieces of functionality.

Also, when class Foo depends on Logger.GetInstance(), Foo is effectively hiding its dependencies from consumers. This means that you can't fully understand Foo or use it with confidence unless you read its source and uncover the fact that it depends on Logger. If you don't have the source, that limits how well you can understand and effectively use the code on which you depend.

The singleton pattern, as implemented with static properties/methods, is little more than a hack around implementing an infrastructure. It limits you in myriad ways while offering no discernible benefit over the alternatives. You can use it however you'd like, but as there are viable alternatives which promote better design, it should never be a recommended practice.

[Padmak]

Das nenn ich mal 'ne Begründung.. ja, ich gebe zu dass das durchaus einige Gründe sind, die dagegen sprechen^^
Ich hab bisher meine sämtliche Erfahrung selbst gesammelt, noch studiere ich das nicht, also bin ich auf solche Sachen angewiesen^^ Außerdem sind alle meine Projekte bisher privat gewesen, da kenn ich meinen Code (mehr oder weniger) und hab daher mit weniger Problemen zu kämpfen. Ich bin mir aber bewusst, dass es nicht der schönste Weg ist (wenn auch eben der einfachste/gängigste)

Mal sehen, vielleicht baue ich mein nächstes Projekt oder so mal anders auf^^

Padmak

[MrSm!th]

Immer diese Kommunismuskritik ;<

Ich wüsste zb nicht, wie in einem Betriebssystem die zentrale Fensterverwaltung nicht Singleton sein sollte. Ohne das wäre ein spezieller Kontext-Parameter für jedes verwaltete Objekt und jeden Nutzer notwendig. Zudem ist die Art von Klassen, für die das Pattern gedacht ist, ja gerade von so globaler Bedeutung, dass ohnehin alles davon abhängt und es nur eine Implementation gibt. Insofern verstehe ich das mit der engeren Kopplung nicht. Wenn man von Polymorphie und anderen Vorteilen von Vererbung absieht, wo genau unterscheidet sich eine Singleton-Klasse von einer normalen, was die Wartbarkeit angeht?

[Schlüsselbein]

Ich hab mich ja nicht komplett gegen Singleton-Objekte ausgesprochen. Sie haben ihre Daseinsberechtigung, ganz bestimmt sogar. Mein Aussage war nur, dass Anfänger in 8 von 10 Fällen das Singleton unnötig benutzen.

Zu deinen anderen Fragen gibts in dem Zitat von oben ja gute Antworten:
Jede Klasse muss _wissen_, dass es ein Singleton ist, was es benutzt. Das erhöht die Abhängigkeit der Klassen.
Und falls man Klassen einzeln testen will, braucht man eben doch meistens verschiedene Implementationen, da man die Klassen ja isolieren will und unabhängig voneinander testen will.
Ich selber muss gestehen, nicht sehr bewandert zu sein, was unit-testing angeht, ich les mich da selber gerade erst ein wenig ein - deshalb kann ich bis hierhin auch großteils nur zitieren.




Gruß

[Padmak]

Ich muss MrSm!th da nur recht geben, wenn ich ein Programm schreibe, sind die meisten globalen Sachen eh dazu da, global nur einmal zu existieren. Und da das meiste ja doch ziemlich Programmabhängig ist, sehe ich auch keinen Grund darin, unnötig auf Wiederverwendbarkeit zu pochen. Wobei man aber zum testen irgendwie immer 'ne andere Implementierung braucht, ob die jetzt über Singletons erfolgt oder nicht ist doch recht egal?

Und, um noch bisschen Brennstoff zu liefern:
Man könnte doch einfach defines nehmen, sowas wie #define SINGL klasse->Instance() ...
*duckundweg*

... Kinder, macht das nicht!

Padmak

[dowhile]

Welchen Vorteile habe ich, wenn solche globalen Klassen das Singleton-Pattern statt statischen Methoden nutzen? (... und wenn ich es nicht in Verbindung mit Polymorphie nutze)

Was ich zu Schlüsselbeins Beiträgen noch ergänzen möchte: DI statt Singletons machen es nicht nur einfacher, Komponenten zu testen, sondern steigert teilweise auch ihre Wiederverwendbarkeit. Wenn ich einen Serive A habe, der B entgegennimmt, verarbeitet und mit Komponent C speichert, könnte ich B auch mit D speichern lassen - was an einem anderen Einsatzort des Services vielleicht nötig sein könnte, wenn ich DI statt Singletons nutze.

Wobei man aber zum testen irgendwie immer 'ne andere Implementierung braucht, ob die jetzt über Singletons erfolgt oder nicht ist doch recht egal?

Wie kannst du mit Singletons die Implementierung austauschen?

[Schlüsselbein]

wenn ich ein Programm schreibe, sind die meisten globalen Sachen eh dazu da, global nur einmal zu existieren.

Das liest sich so, als hätte jede Anwendung unzählige globale Variablen und Objekte. Überdenke vielleicht nochmal das komplette Design, bevor man dann einfach Singletons hinklatscht.

[Padmak]

Also iwie streite ich hier mit euch über ein Thema, von dem ich (noch) nichts verstehe. Alle meine Anwendungen waren bisher streng auf ein einziges Spiel bezogen, was davon austauschbar sein muss ist's dann auch. Wenn ich aber z.B. in einem Spiel eine MainCharakter-Klasse hab, die dann so Sachen wie Inventar etc beinhaltet als Singleton realisier, passt das doch, oder?

Mit Interfaces etc hatte ich noch nie zu tun, das werd ich iwann wohl mal angehen müssen^^

€: Das liest sich vielleicht so, in Wirklichkeit ist es aber so nicht. Nur was global sein MUSS ist halt in einem Config-Singleton drin, der Rest ist schon strukturiert + aufgeteilt

Padmak

[Schlüsselbein]

einem Spiel eine MainCharakter-Klasse hab, die dann so Sachen wie Inventar etc beinhaltet als Singleton realisier, passt das doch, oder?

Das hört sich schon etwas merkwürdig an. Mit etwas Code und mehr Informationen zu dem Spiel könnten wir etwas mehr damit anfangen.