spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Mal sehen: Der Vorteil von Singletons ist, dass du nicht aus versehen ein zweites Objekt anlegen kannst, welches du dann statt dem Original benutzt. Explizit kriegt man das nur mutwillig hin, also reicht es prinzipiell, das Ding unkopierbar zu machen. Weil wohl niemand auf die Idee kommen wird, ein Rendererobjekt lokal zu erstellen, weil er gerade nicht weiß, wie er auf das richtige Rendererobjekt zugreifen soll, ist der Nutzen von Singletons sehr gering, aber diesen einen Fehler fängt es dann doch ab.

Ansonsten ist es wie ein Globales Objekt. Der Nachteil von Globalen Sachen ist, dass man sie von überall manipulieren kann. So erhöhst du die Abhängigkeiten in deinem Code, und je verstrickter der ist, desto wahrscheinlicher sind Fehler. Außerdem sind globale Objekte bei mehreren Threads manchmal ein Problem, allerdings würden die hier angesprochenen Objekte eh über die Threads verteilt genutzt, da ist es auch egal.
Und ob du jetzt ein globales Objekt hast oder Zeiger über 17 Ebenen durchreichst macht letztendlich keinen Unterschied, außer dass du bei letzterem mehr Code schreiben musst (was die Übersichtlichkeit verhindert und somit schlecht ist). Zeiger durchreichen macht dann sind, wenn es verschiedene Rendererobjekte geben kann, und mal die eine oder mal die andere benutzt werden soll. Wenn du schon an Singletons überlegst, trifft das also sicherlich nicht zu.

Man kann aber ja eigentlich auch von "fast globalen" Objekten sprechen. Zum Beispiel die Skriptverwaltung oder der Renderer könnte levelspezifisch sein (und jeweils alle Objekte/Skripte dieses Levels verwalten). Das würde bei globalen Objekten dann Probleme machen, sobald ein Leveleditor mehrere Levels gleichzeitig editieren können soll. Die Lösung wäre diese Objekte irgendwie in einer Levelklasse zu speichern, auf die dann wieder jedes Objekt im Level einen Zeiger hat, um den korrekten Skriptmanager zu benutzen. Das kann bei vielen Verwaltungsklassen dann natürlich sehr nützlich/wichtig sein.

Ich würde sämtliche Singletons vernichten. Falls Du nämlich wirklich mal mehrere parallele "Engines" brauchst (Editor, multiple Fenster, whatever), dann wäre das mit Singletons nicht möglich.
Zu Accessor-Methoden neigt man immer man wieder, weil man eben doch einen ganzen Haufen von Managern oder sowas hat und die nicht alle einzeln übergeben will. Würde ich aber von abraten. Dann schreib lieber einen Ober-Manager, der alle anderen verwaltet und übergib diesen an die Stellen, die ihn brauchen. So kannst Du jederzeit beliebig viele haben.

Du hast also den klassischen Fall von Singletons, die eigentlich keine Singletons sein sollten, sondern globale Variablen. Die bessere Lösung wäre Dependency Injection oder auf gut Deutsch: Wenn ein Objekt ein anderes kennen muss, gibt man ihm eine Referenz drauf...

Oder Du legst halt eine globale Instanz der Engine an. Die potentiellen Probleme damit wurden ja schon beschrieben, aber es gibt auch Vorteile einer global erreichbaren Instanz: Du kommst jederzeit leicht ran, was anfangs einige Arbeit erspart und schneller zu Ergebnissen führt.

Ein Singleton dagegen ist meiner Meinung nach einfach nur unnütz. Das "Pattern" könnte von heute auf morgen verschwinden und niemand würde darunter leiden.

Bei Splatter habe ich übrigens den Renderer in eine eigene Klasse gepackt und in der Tat bald mehrere Instanzen davon gebraucht. Z.b., um im Multiplayer-Menü mal schnell eine kleine Welt zum Ausprobieren der Steuerung in die GUI zu rendern. Oops... doch nicht so single wie gedacht. Die großen Texturen und sowas stecken allerdings in einem Manager, der in der Tat als globale Instanz rumliegt. Allerdings spricht ja auch nix dagegen, sich für spezielle Zwecke einen zweiten ResourceManager aufzumachen, der seine Aufgabe erledigt und danach wieder sauber abgebaut wird. Man kann sich mit einem Singleton wirklich sehr schön die Zukunft verbauen, und hat außer verletztem Stolz eigentlich nie Nachteile, wenn man ihn wieder ausbaut.

Zitat von »Schrompf«

[...] aber es gibt auch Vorteile einer global erreichbaren Instanz: Du kommst jederzeit leicht ran, was anfangs einige Arbeit erspart und schneller zu Ergebnissen führt.

Das ist imo kein Vorteil, sondern gerade das fundamentale Problem von globalen Variablen. Denn anstatt sich Gedanken über Design zu machen, wirft man von da an mit Abhängigkeiten nurmehr so um sich, meist ohne dass es einem überhaupt auffällt. Globale Variablen sind ein Seitenkanal, durch den Abhängigkeiten abseits aller Schnittstellen in ganzen Source metastasieren können und meistens auch tun. Und wenn man es dann endlich merkt, ist es oft schon zu spät...

Hm, wenn du eh alle Zeiger durchreichst, was hast du dann im Gegensatz zu einem globalen Objekt gewonnen? Wenn vom Design her alle Enginekomponenten eh auf das selbe Engine Objekt zugreifen, ist es quasi global. Der Vorteil wäre natürlich, dass du wegen der ganzen Zeiger siehst, wo es überall benutzt wird und du dadurch evtl. animiert wirst an ein paar Punkten das Design zu ändern, dass es nicht mehr benutzt wird. Aber solange du das nicht machst, hast du einfach nur ne Menge Zeigerkopiercode geschrieben und immer noch die selben Abhängigkeiten.

Zitat von »Jonathan_Klein«

Hm, wenn du eh alle Zeiger durchreichst, was hast du dann im Gegensatz zu einem globalen Objekt gewonnen?

Viel, die Abhängigkeiten sind nun explizit in den Interfaces ausgedrückt. Man wird also dazu gezwungen, sich über Abhängigkeiten Gedanken zu machen, sich mit der Frage von Scope und Besitzverhältnissen auseinanderzusetzen. Plötzlich ist es z.B. rein prinzipiell unmöglich, Objekte in der falschen Reihenfolge zu initialisieren, da man sowas nun gar nichtmehr hinschreiben oder gar kompilieren kann; der ganze Code wird automatisch sauberer und das Design flexibler...

Zitat von »Thoran«

Wenn ich dots Empfehlung folge, Dependency-Injection zu verwenden, müßte ich natürlich meine Enginebibliothek umschreiben und die Instanz der Engineklasse überall druchreichen, was dazu führt, dass ich beim Aufräumen der gesamten Engine (also Speicherfreigabe) gut Aufpassen muss keine Danglingpointer mehr zu haben. evt. bietet sich dann hier wohl die Verwendung eines Smartpointers an.

Wenn du Probleme mit dangling Pointern bekommst, dann ist das ein Hinweis drauf, dass die Besitzverhältnisse zwischen deinen Objekten nicht wirklich klar sind. Smartpointer solltest du sowieso verwenden (std::unique_ptr)...