spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Das wird Dir jetzt nicht gefallen, aber: Mach weder A, noch B zum Singleton. Ein Singleton sollte nur verwendet werden, wenn es unter gar keinen Umständen mehr als eine einzelne Instanz einer Klasse geben darf. Bei Dir scheint mir das nicht plausibel und eher so, als würdest Du es verwenden wollen, weil Du weißt, dass es das gibt. Finger weg davon. Du brauchst es nicht, arbeite ohne. Härter ausgedrückt solltest Du es auf keinen Fall verwenden, egal was im Buch steht, eigne Dir das gleich als eiserne Regel an und Du sparst Dir viel Ärger und Probleme, weil Du Singleton falsch verwendet hast. Sie sind schlechter Stil (werden verwendet wie globale Variablen, die ebenfalls sehr schlechter Stil sind) und Hinweis auf schlechtes Code-Verständnis.

Zitat von »Clark«

EDIT2: Simpler gefragt.. nehmen wir mal an ich habe Game.Run() (Klasse) laufen.. wo halt die Eventschleife ist und das Spiel stattfindet. Jetzt will ich dort drin z.B. den Timer ansprechen (der auch eine Klasse ist).
Wie geht das?

Na dann hast du in der Klasse "Game" eine Membervariable(Ich hoffe du weißt was das ist?) vom Typ "Timer". Das Timer-Objekt kannst du ja im Konstruktor der Game-Klasse erzeugen. Also du hast ja die Klassen in der Regel dafür, um Objekte von deren Typ zu erstellen - Man benutzt ja nicht die Klasse selber, sondern ein Objekt davon, außer du machst alles static aber dann ist hast du quasi den gleichen Designfehler wie mit Singletons, und könntest dann auch nicht mehr als bspw. 1 Timer haben...

Zitat von »Clark«

Nehmen wir mal an ich hab 5 Klassen und die müssen alle gegenseitig aufeinander zugreifen in Punkto Variablen und Funktionen .. wie realisiere ich das denn?

Am besten gar nicht, das klingt dann sehr nach Spagetti-Code ; ) Überleg dir lieber genau was für Klassen du brauchst, und wie diese voneinander abhängig sind. Wenn du dir da zu deinem Entwurf eine Meinung holen willst, kannst du das natülrich hier gerne machen.

Also deine Überlegungen sind schon nicht so falsch, nur die Schlüsse die du daraus ziehst, passen nicht so recht. Im Grunde willst du, dass alle (bisher 2) Klassen denselben Timer verwenden - und daraus schlussfolgerst du jetzt, die Klasse Timer als Singleton zu machen. Das ist aber nicht logisch, denn was wenn du später einen weiteren Timer brauchst? Dann klappt es nicht. Und genauer gesagt - was spricht dafür, dass ein Timer nur einmal existieren sollte? Ein Singleton macht wirklich nur selten Sinn. (Bei einem Ressourcen-Manager hätte man vielleicht einen sinnvollen Einsatz) Das mit der Logfile-Klasse, da hast das schon besser getroffen, hier ist es durchaus keine schlechte Idee, die Klasse als Singleton zu machen, das kannst du also so machen (wobei man sich da natürlich auch streiten kann, ob man nicht vllt. mehrere Logfiles haben will etc).

Also, du hast ja jetzt schon die Abhängigkeiten deiner Klassen erläutert: Game benutzt Player, und Game und Player benutzen denselben Timer. Was also spricht dagegen, wenn du den Timer in der Game-Klasse erzeugst, danach das oder die Player-Objekte erzeugst (in Game), und diesen Objekten eine Referenz auf das bereits erzeugte Timer-Objekt übergibst? Dann bräuchtest du auf jeden fall den Timer nicht global.

Als nächstes könnte man natürlich noch fragen, wieso die Klasse Player den Timer überhaupt braucht, und nicht einfach die Klasse Game in jedem Schleifendurchlauf bei allen Player-Objekten sowas wie update() aufruft (und dort eventuell noch die vergangene Zeit oder sowas mit übergibt) - dann hättest du in der Player-Klasse ein Problem weniger und eine zentrale Stelle, an der die Zeit-Sachen berechnet werden,

Jup, Powerpaule hat vollkommen Recht. Geteilte benutzte Ressourcen an einer Stelle verwalten und den Instanzen übergeben, die diese brauchen: Das Game erstellt eine Timer-Instanz und den übergibt es (am besten gleich im Konstruktor) an die ebenfalls von ihm erzeugten Player-Instanzen. Auf Member-Variablen greifen die Player hoffentlich ohnehin nicht zu, sondern nur auf Get-Methoden der Timer-Klasse.

Damit kannst du mehrere Game-Objekte und mehrere Timer-Objekte erstellen - mehrere Timer könnten nützlich sein für Menü und den Spielfluss, die verschiedene Timer brauchen, mehrere Game-Objekte könnten z.B. in einem Level-Editor notwendig oder hilfreich sein, damit man mehrere Levels bearbeiten kann statt immer nur eins im Speicher haben zu können. Singletons wären da in jedem Fall die falsche Wahl.

Auch der Wunsch nach "von überall drauf zugreifen können" ist verständlich, aber sehr sehr schlechter Stil und Fehler im Design. Man sollte Objekte, die ein anderes Objekt braucht, immer an dieses übergeben und nicht wahlfrei quer durch die Klassen-Hierarchie Zugriffe erlauben.

das Problem an Designfehlern ist, dass sie der Person, die sie entwickelt hat, meist nicht oder nicht sofort auffallen
ich würde vorschlagen, du kannst dein Design in Form von UML-Klassendiagrammen darstellen und uns fragen, ob wir darin schwächen erkennen können
solltest du dich mit Klassendiagrammen bisher nicht auseinander gesetzt haben, so würde ich das empfehlen, vor allem, wenn du später in den Bereich der Softwareentwicklung gehen willst