Einstellungen in's OOP Schema Pressen
-
Hoi
Welche Objekte besitzen bei euch eigentlich Einstellungen? Also Dinge wie Tastenbelegung, Auflösung, Grafikstufe, etc.?
Also nicht die Einstellungen selbst (die werden ja sinnvollerweise von extra Objekten gehalten), sondern wer besitzt die Objekte, die die Einstellungen kennen?
-
cooky451 schrieb:
die werden ja sinnvollerweise von extra Objekten gehalten
Wie genau meinst du das?
Für mich hört sich das nicht uneingeschränkt sinnvoll an.Ohne weitere Informationen zur Architektur eines Systems gibt es dafür meines Erachtens keine Patentlösung.
-
cooky451 schrieb:
wer besitzt die Objekte, die die Einstellungen kennen?
Niemand. Ist ein Singleton/globale Variable
-
JFB schrieb:
cooky451 schrieb:
die werden ja sinnvollerweise von extra Objekten gehalten
Wie genau meinst du das?
Für mich hört sich das nicht uneingeschränkt sinnvoll an.Eine Klasse bekommt im Konstruktor einen Dateinamen, liest die Einstellungen da raus und stellt sie über ein Interface zur Verfügung. Zudem kann man natürlich auch Einstellungen hinzufügen/ändern. Im Destruktor wird dann alles zurück in die Datei geschrieben.
@Shade Of Mine
Hmtja. Globale Variablen würden natürlich schon gehen. Vielleicht muss ich mich ja auch einfach mal überwinden und meinen ästhetischen Anspruch etwas zurücknehmen..
-
cooky451 schrieb:
JFB schrieb:
cooky451 schrieb:
die werden ja sinnvollerweise von extra Objekten gehalten
Wie genau meinst du das?
Für mich hört sich das nicht uneingeschränkt sinnvoll an.Eine Klasse bekommt im Konstruktor einen Dateinamen, liest die Einstellungen da raus und stellt sie über ein Interface zur Verfügung. Zudem kann man natürlich auch Einstellungen hinzufügen/ändern. Im Destruktor wird dann alles zurück in die Datei geschrieben.
Naja, damit hast du deine Lösung dann ja auch schon gefunden!?
-
singleton klingt fuer mich nach der logischen entscheidung.
-
dot schrieb:
Naja, damit hast du deine Lösung dann ja auch schon gefunden!?
Neja, die Frage war ja, wer diese Objekte dann wieder besitzt. Globale Variablen/Singleton wurden vorgeschlagen - was natürlich ginge. Ich frage mich halt nur gerade, ob man nicht schönere Besitzverhältnisse abbilden könnte. Aber dem scheint ja nicht so zu sein.
-
cooky451 schrieb:
Neja, die Frage war ja, wer diese Objekte dann wieder besitzt.
cooky451 schrieb:
Eine Klasse bekommt im Konstruktor einen Dateinamen, liest die Einstellungen da raus und stellt sie über ein Interface zur Verfügung.
Der da? Wie dot schon gesagt hat.
-
Offen gesagt verstehe ich gerade nicht so ganz, was du mir sagen willst..
-
cooky451 schrieb:
Ich frage mich halt nur gerade, ob man nicht schönere Besitzverhältnisse abbilden könnte. Aber dem scheint ja nicht so zu sein.
Naja. Einstellungen sind ja wie Compile Konstanten, nur eben dass sie zufälligerweise vom User gesetzt werden können.
Wenn du zB die Fenstergröße als Compile Konstante nehmen würdest, hättest du doch auch kein Problem ein
Window wnd(WND_HEIGHT, WND_WIDTH);
zu schreiben, oder?
Nur dass du jetzt halt
Window wnd(Properties::get(WND_HEIGHT), Properties::get(WND_WIDTH));
schreibst.
-
Shade Of Mine schrieb:
cooky451 schrieb:
wer besitzt die Objekte, die die Einstellungen kennen?
Niemand. Ist ein Singleton/globale Variable
sowas von dir? ich bin maßlos enttäuscht.
-
Oft habe ich eine Top-Level-Klasse, welche Klassen für die wichtigen Module wie Input, Grafik, ... und eben eine solche Config-Klasse enthält. Die Modulklassen, die Zugriff auf die Einstellungen benötigen, erhalten eine Referenz auf die Config-Klasse im Konstruktor.
-
Nexus schrieb:
Oft habe ich eine Top-Level-Klasse, welche Klassen für die wichtigen Module wie Input, Grafik, ... und eben eine solche Config-Klasse enthält. Die Modulklassen, die Zugriff auf die Einstellungen benötigen, erhalten eine Referenz auf die Config-Klasse im Konstruktor.
Durch die Referenz werden die Klassen aber alle Non-Copyable.
-
pyhax schrieb:
Durch die Referenz werden die Klassen aber alle Non-Copyable.
Ne, ich sagte "Referenz erhalten", nicht "Referenz speichern", du kannst immer noch einen Zeiger verwenden. Aber abgesehen davon sind die Modulklassen meist sowieso noncopyable und werden nur einmal instanziiert.
