Hi, ich hätte da nochmal eine Designfrage.
Sagen wir, ich habe 3 Klassen: SoundManager, SoundFile (ein geladener Sound), SoundController (Instanz eines gerade abgespielten Sounds mit Kontrollmöglichkeiten). Bisher ist das Konzept, dass der SoundManager SoundFiles erstellt, und SoundFiles SoundController. Die Konstruktoren sind daher private (und die Klassen befreundet). Soweit bin ich damit zufrieden, man weiß wo seine Objekte herkommen, und das sie immer korrekt initialisiert sind.
Das Problem ist nun, Spielobjekte haben Sounds, aber vielleicht macht nicht jeder Gegnertyp Geräusche beim Laufen. Ich brauche also irgendeine Möglichkeit, leere Sounds darzustellen. Spontan sehe ich da zwei Möglichkeiten:
- Ich verpasse beiden Klassen doch einen 'leeren' Konstruktor ohne Argumente, die intern alles auf 0 setzen. Dann muss die Klasse aber damit umgehen können, dass sie in einem ungültigen Zustand sein kann, eine Play-Methode müsste also prüfen ob ein Sound geladen ist. Das zieht sich dann durch alles durch. Und es verletzt irgendwie RAII.
- Ich benutze unique_ptr für optionale SoundFiles / Controller. Objekte die existieren sind damit immer gültig, und die Optionalität wird explizit modelliert. Man müsste in der Spielobjektklasse dann abfragen, ob ein Sound existiert (schön, weil man sieht, dass der Sound optional ist?), aber wenn man es vergisst, knallt es. Zusätzlich hat man eine Indirektion mehr, was erstmal langsamer sein dürfte, die Frage ist, ob es messbar ist.
Welche Variante findet ihr besser? Mit welchen Argumenten?
RAII only Objekte
RAII only Objekte
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
https://jonathank.de/games/
Re: RAII only Objekte
Danke, das sieht ganz gut aus.
Leider bin ich noch mit VC2015 unterwegs, und habe gerade eigentlich keine Lust zu wechseln, am Ende geht noch was mit den Abhängigkeiten kaputt und ich brauche das ganze Wochenende bis es wieder läuft.
Ich vermute für jetzt ist dann ein unique_ptr die beste Lösung: Das sieht vom Code her ähnlich aus und ich schreib mir ein dickes TODO dran, das durch std::optional zu ersetzen, sobald ich mit einer neuen Compilerversion unterwegs bin. Und da es sich um Sound-Objekte handelt (von denen es eh nicht so viele gibt), dürfte der Performanceverlust bis dahin recht überschaubar bleiben.
Leider bin ich noch mit VC2015 unterwegs, und habe gerade eigentlich keine Lust zu wechseln, am Ende geht noch was mit den Abhängigkeiten kaputt und ich brauche das ganze Wochenende bis es wieder läuft.
Ich vermute für jetzt ist dann ein unique_ptr die beste Lösung: Das sieht vom Code her ähnlich aus und ich schreib mir ein dickes TODO dran, das durch std::optional zu ersetzen, sobald ich mit einer neuen Compilerversion unterwegs bin. Und da es sich um Sound-Objekte handelt (von denen es eh nicht so viele gibt), dürfte der Performanceverlust bis dahin recht überschaubar bleiben.
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
https://jonathank.de/games/