spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Wenn Du das konkrete Objekt aber eh per Interface in den Nutzer reinreichst, warum machst Du dann überhaupt ein Singleton? Dann kannst Du doch auch einfach das Objekt anlegen und halt reinreichen als klassische Dependency Injection? Oder habe ich da was missverstanden?

Bei dem Singleton gehe ich davon aus, dass die eine Voraussetzung gegeben ist, die einen Singleton sinnvoll macht: es darf nur 1 Instanz geben.
Dass das oft genug nicht gegeben ist, habe ich ja bereits erwähnt. Und ich wollte nicht sagen, dass man bei einer solchen Implementierung Singleton "ruhigen Gewissens" verwenden kann. Aber die meisten Probleme (globale Zugreifbarkeit, woraus starke Bindung, schlechte Testbarkeit etc. resultieren) sind immernoch durch die Standardimplementierung bedingt.
Wie genau die Instanz weitergereicht wird habe ich nicht bestimmt und ich habe auch geschrieben, dass Dependency Injection weitere Möglichkeiten bieten würde. Dazu kann man auch zählen, dass das Instanziieren durch das Framework übernommen wird. Da ich aber die Beispiele nicht von konkreten Frameworks abhängig machen wollte, habe ich es an einem Beispiel ohne DJ-Framework gezeigt.

Also: jain. Letztendlich würdest du es wohl richtig machen, indem du einfach einen Schritt auslässt und direkt auf Singletons verzichtest.

Ich denke das einzige gute Argument fuer Singletons ist Faulheit.

Sicherlich wuerde es flexibler und besseres testen erlauben wenn man eine Logger Instanz in jede Klasse schieb. Aber es ist doch durchaus angenehmer und weniger Arbeit das einfach als Singleton (oder ein aehnliches global verfuegbares Pattern) zu verwenden. Weniger Code, weniger zu maintainen, weniger zu refactorn... Faulheit hat manchmal durchaus was gutes

Zitat von »xardias«

Ich denke das einzige gute Argument fuer Singletons ist Faulheit.

Oder wenn eine Instanz einer Klasse nur ein einziges Mal in deiner Software vorhanden sein soll

Zitat von »Jar«

Zitat von »xardias«

Ich denke das einzige gute Argument fuer Singletons ist Faulheit.

Oder wenn eine Instanz einer Klasse nur ein einziges Mal in deiner Software vorhanden sein soll

Was in keiner Software, von der ich je gehört hätte, sinnvoll ist. Faulheit ist der einzige wirkliche Grund für so ziemlich alle Singletons, die je geschrieben wurden und geschrieben werden. Siehe auch: https://en.wikipedia.org/wiki/Technical_debt...

Zitat von »LetsGo«

Zitat von »dot«

Was in keiner Software, von der ich je gehört hätte, sinnvoll ist.

Wenn man alle Beispiele, die andere anführen ignoriert ist das auch kein Wunder.

Keine Sorge, ich hab mir alle hier im Thread angeführten Beispiele natürlich angeschaut und beim Tippen meiner obigen Aussage bedacht...

Ich muss mich dot da leider anschließen. Wenn es, wie Jar meinte, nur eine Instanz geben soll, dann reicht es, nur eine zu instanziieren.
Wenn es nur eine geben darf, weil sonst igendwas nicht richtig funktionieren würde, liegt das Problem meist an einer anderen Stelle.
Und wenn man die Standardimplementierung des Singletons verwendet (also mit globalem Zugriff und so), dann ist man ohnehin faul.

Wobei reine Faulheit als in jedem Fall schlecht abzutun auch nicht immer richtig ist. Auch wenn ich euch zustimme und aus vielen Faulheitsfällen später größere Probleme entstehen können, wie zum Beispiel dass dadurch das Softwaredesign gestört wird und am Ende nicht ohne weiteres wieder korrigiert werden kann. Faulheit hat nicht unbedingt immer Nachteile. Wie gesagt, die Aussage bezieht sich jetzt weniger auf Singleton. Eher auf Faulheit im allgemeinen. Es gibt eben manchmal Gründe warum Faulheit vielleicht doch nicht so schlecht sein kann. Als Beispiel muss nicht immer endlos viel Zeit in Dinge gesteckt werden die am Ende nicht benötigt werden. Das ist eben unwirtschaftlich. Aber bitte nicht falsch verstehen.