Singleton vs unnamed namespace
-
Eisflamme schrieb:
Hmm... Wieso sind manche Dinge statisch und andere nicht?
Bei den globalen: Aus Tradition, nur aus Tradition, ohne, daß das besonders sinnvoll wäre.
-
Vollkommen falsch! Falsch. Falsch. Falsch. Falsch. Falsch.
Dazu zitiere ich mich einfach mal selbst
Entweder also programmierst du von Anfang an so das du x Welten erwartest, und machst dir falls du es nie braucht völlig unnötige Arbeit, oder aber du erlaubst es ein Objekt zu kopieren das logisch gesehen eben nicht kopiert werden darf.
Der Text ging eben unter der Annahme, dass das restliche Programm bereits mit mehreren instanzen umgehen kann.
Du bist also der Meinung du schreibst stunden um stunden code um mehrere Welten zu unterstützen die du vielleicht mal brauchen KÖNNTEST? Bitte, verbiete ich dir nicht. Ich spar mir diese Arbeit - und mach konsequenterweise dann eben die Instanz, dies nur einmal geben darf zu einem singleton. Und falls sich doch tatsächlich die Anforderung ändert, kann ich diese Änderungen nachliefern. Das es syntaktisch bis dahin ein singleton war stört mich nicht weiter, weil eben nur das umzustellen ist ein moderator wenn auch zugegebenermaßen relevanter aufwand. Der logische/Design- Aufwand ist deutlich größer - egal ob man das jetzt von Anfang an macht oder nachholt.
Nur häufig baut man sich halt nunmal Flexibilität mit viel mühen die man niemals braucht. Man kann sich natürlich wunderbar streiten was mehr arbeit macht, nachrüsten oder alles "richtig" machen damit man, falls man später etwas tatsächlich braucht weniger arbeit hat. Ist auch eine Frage wie wahrscheinlich es ist das sich entsprechende Anforderungen ändern. Muss man abschätzen, und wenn ich der Meinung bin es ist unwahrscheinlich das ichs später brauche mach ich ein singleton draus, inklusive vereinfachter logik. Deswegen überzeugt mich dieses Gebetsmühlenartige "aber man könnte es später ja mehrmals brauchen" auch nicht. Diese Aussage ist zwar imho völlig korrekt, aber leider nicht das einzige, was es zu beachten gibt.Und btw, auch im multiplayer gibt's nur eine Welt. Es gibt mehrere Spieler, aber (vom Modell her) immer noch eine Welt. Oder spielt dein Multiplayer in zwei verschiedenen leveln? (tatsächlich hat natürlich jeder seine eigene Kopie, und um das zu synchronisieren gibt's halt oft einen server der DIE EINE Welt hält und entscheidet was jetzt wie ist - die anderen haben eher nur ein Abbild)
-
Nur falls sich jemand wundert, Volkard hat nachdem ich zitiert habe seinen Text noch leicht geändert. (darfst gerne meinen post oben korrigieren und den hier löschen, inhaltlich ändert sich ja nichts)
-
Viele Klassen kann man doch schreiben und sie nur einmal benutzen. Oft ist es kein Problem sie mehrfach zu nutzen bzw. erfordert das nur wenige Erweiterungen. Die Klasse zum Singleton zu machen ist da sogar mehr Arbeit.
-
Sowas würd ich auch nicht zum Singleton machen. Wenn mehrere Instanzen einer Klasse kein Problem sind, gibt es ja keinen Grund mehrere Instanzen einer Klasse zu verbieten. Beispiel: Eine Konsole zur Eingabe von Befehlen (z.B. zum debuggen) während dem laufenden Programm. Wenn das abfangen der Tastatureingaben entsprechend gebaut ist, gibt's da kein Problem davon 5 auf einmal zu haben - selbst wenn man nur eine auf einmal sinnvoll verwenden kann.
Andersrum würde ich die Art und Weise wie ich Tastatureingaben handhabe nicht ändern, nur um 5 solche Konsolen starten zu können. Das lass ichs dann lieber als singleton.
-
Wenn Du eine Klasse bastelst, ist es aber doch immer so, dass alles darin Gebaute für Mehrfachinstanziierung klappt. Du erzeugst dort benötigte Objekte, die am Ende wieder zerstört werden, und alles Verwendete kann man über die Methoden beeinflussen und nutzen.
So was wird naturgemäß nicht zum Singleton gemacht. Aus deinen Aussagen ging hervor, dass Du eine Klasse, die nicht mehrere Instanzen haben würde, lieber zum Singleton machen würdest. Später schränkst Du das auf Klassen ein, bei denen eine Verwendung von mehreren Instanzen zusätzlichen Aufwand benötigen würde, sodass Du diese dann, falls es eh erstmal nur eine logische Instanz gibt, zum Singleton machst.
Aber was für Klassen sollen das denn sein? Die meisten sind eben schon durch den Aufbau einer Klasse mit ctor/dtor an sich so gebaut, dass man die mehrfach nutzen kann, das ist der Standard und nicht andersrum.
Und volkard meint nur, wenn es nicht absolut auszuschließen ist, dass man eine Klasse "Universum" mehrfach nutzen wird, sollte man die eben nicht zum Singleton machen, auch wenn die vorläufige Planung nur ein Objekt vorsieht.
-
Eisflamme schrieb:
Und volkard meint nur, wenn es nicht absolut auszuschließen ist, dass man eine Klasse "Universum" mehrfach nutzen wird, sollte man die eben nicht zum Singleton machen, auch wenn die vorläufige Planung nur ein Objekt vorsieht.
Nicht ganz. Auch wenn ich absolut ausschließen kann, daß man eine Klasse "Universum" mehrfach nutzen werde, mache ich sie nicht einfach zum Singleton. Sondern erst, wenn ich verbieten muß, daß es sie mehrfach gibt. Zum Beispiel, weil es ich der Einfachheit halber nicht durchreichen will. Die Konsole zum Beispiel, falls es eh sowas wie Fenster gibt, Eingabedialoge, dann kann das Spiel ja schon die Tastatureingabe ans aktive Fenster/Dialog/Editbox weiterleiten. Da gibt es überhaupt keinen Grund, die Konsole zum Singleton zu machen. Allein, ich lege nur eine davon an.
-
Aus deinen Aussagen ging hervor, dass Du eine Klasse, die nicht mehrere Instanzen haben würde, lieber zum Singleton machen würdest
Nein, das ist ein notwendiger Grund, kein hinreichender. Nur weil ich denke ich brauch nur eins davon, mach ichs noch nicht zum singleton. Ein singleton wirds dann, wenn ich denke es wird nur eins davon geben und wenn es mehrere geben würde, würde es probleme verursachen um die ich mich kümmern müsste.
Ein Beispiel wäre eine Klasse die ein archiv öffnet (und ich brauche in dem Programm nur ein enziges archiv) und daten rein und raus schreibt. Gäbe es das mehrmals, müsste ich das archiv immer wieder schließen, um anderen instanzen der Klasse zugriff auf dasselbe archiv zu erlauben. Verzögertes schreiben oder ähnliches muss ich dann alles koordinieren. Gibt's das nur einmal, weil ichs nur einmal brauche kann ich mir sparen mich um solche Probleme zu kümmern.
Ich hab also entweder die wahl mich um jede beliebige kombination zu kümmern wie man diese Klasse verwenden könnte, mit allen methoden die sich ins gehege kommen könnten - oder ich verbiete einfach mehr als eine instanz.Die meisten sind eben schon durch den Aufbau einer Klasse mit ctor/dtor an sich so gebaut, dass man die mehrfach nutzen kann, das ist der Standard und nicht andersrum.
Natürlich ist bei einem Programm mit mehr singletons als normalen klassen zu 99% irgendwas falsch gelaufen. In den meisten fällen stellt sich aber die Frage nicht, weil man naturgegeben die meisten dinge mehrmals braucht. Bei den Dingen die man normalerweise nur einmal braucht, gibt es auch einen Grund dafür WARUM das oft so ist.
Die Konsole zum Beispiel, falls es eh sowas wie Fenster gibt, Eingabedialoge, dann kann das Spiel ja schon die Tastatureingabe ans aktive Fenster/Dialog/Editbox weiterleiten. Da gibt es überhaupt keinen Grund, die Konsole zum Singleton zu machen. Allein, ich lege nur eine davon an.
Dem stimme ich zu. Der wichtige Punkt hier ist halt das "falls". (auch wenn eventuell die Konsole ein schlechtes Beispiel von mir war). Denn falls es sowas nicht gibt, mache ich es ganz natürlich zum singleton und mach mir nicht die Mühe dass es das, was hinter dem "falls" steht erstmal zu implementieren. Ich seh da gar keinen Grund dafür.
Absolut ausschließen das man etwas mehrfach nutzen will kann man doch eigentlich eh nie. "Man könnte ja mal 2 brauchen" als Grund zu sehen in einem Fall kein Singleton zu machen bedeutet also, nie welche zu verwenden. Und dem muss ich widersprechen.Nur mal um etwas von Verhältnissen zu reden: Für 90-95% des codes gibt's imho keinen Grund Singletons zu machen. Und beim rest muss man sichs halt überlegen. Gibt ja noch andere Gründe die dagegen Sprechen - afaik beißt sich das pattern mit unit-testing.
-
Dann seid ihr zwei euch doch etwa einig. Immer diese Kommunikationsschwierigkeiten.
Wo waren wir davor?
-
kleiner Troll schrieb:
Naja, was ist für dich "größer"?
200k+ Zeilen? Nö hab ich zugegebenermaßen nicht.
20k+ Zeilen? Jop.Naja, 20k ist noch eher klein.
Sicher ist das nicht ne Sache von 5 Minuten, zumindest je nachdem wie tief das Singleton im Programm verankert ist.. Aber da es prinzipiell eine einfache Aufgabe ist muss man sich nicht so viele Sorgen um bugs die man einführen würde während dieser arbeit machen.
"Tage" dauern würd ich für übertrieben halten,zumindest wenn man die variante mit der globalen variable nimmt.
Kann man ja einfach nach namespace::GetInstance() suchen und das entsprechend ersetzen. Logisch muss man am code ja überhaupt nichts ändern.Du willst nen Singleton gegen eine globale Variable austauschen? Soll das ein Scherz sein? Was soll das bitte bringen?
Schwieriger wirds natürlich wenn man auf dependency injection umstellt. Aber auch das seh ich als machbar an - vorallem als viel weniger arbeit als ein Riesenprogramm auf spezifikationen auszulegen, dies in 80% der Fälle nie brauchen wird.
Wie oft hast du es denn schon gemacht?
Man abgesehen davon dass die Alternative zu nem Singleton nicht unbedingt Dependency-Injection heissen muss.
