Config-Klasse, Elemente statisch oder Datei jedesmal neu einlesen

stefkowa

Hallo!

Ich bin dabei mir eine Config/Settings-Klasse zu schreiben. Die Klasse übernimmt das Lesen und Schreiben der Daten in bzw. aus der Datei. Damit die Datei nicht bei jedem Abfragen eines Wertes neu geöffnet, gelesen und geschlossen werden muss, dachte ich mir, ich lege die eingelesenen Daten statisch in der Klasse ab. Nur sind sie dann, wenn ich es richtig verstehe, in eine Klasse gepackte globale Variablen. Was ja vom Design her wohl auch nicht so gut ist.

Wie ist hier die beste Vorgehensweise?

- Daten/Elemnte statisch machen
- Datei bei jedem Aufruf neu einlesen
- ganz anderer Weg

Was würdet ihr empfehlen?

Wieso statisch? Eine Konfiguration ist erst einmal eine normale Klasse ohne statische Member.

Im Idealfall hast du dann eine Instanz dieser Klasse in main und übergibst die Einstellungen dann an die Funktionen, die sie brauchen.

Wenn dir das zu mühsam ist und dein Design schon so verkorst ist, dass das kaum umsetzbar ist, dann mach halt eine globale Variable vom Typ dieser Konfigurationsklasse.

Auf jeden Fall zu vermeiden ist: Singleton, statische Member.

Leider wird in der Praxis für Config meistens ein Singleton benutzt.

stefkowa

Es gibt (oder soll es geben) mehrere Klassen die je 1-3 Werte in dieser Datei hätten. Zum Beispiel die WindowKlasse: Fenstergröße und Position.

In der main gibt es nur die WindowKlasse. Bei einer Instanz der ConfigKlasse in der main, müsste ich diese dann an die WindowKlasse weiter reichen und von dieser an die anderen Klassen, die Werte aus der Config brauchen.

Selbst wenn ich die Instanz der ConfigKlasse erst in der WindowKlasse erzeuge, müsste ich sie immer noch an die anderen Klassen durchreichen. Auch durch Klassen durch, die sie selbst garnicht brauchen. Wäre sicher auch nicht das Wahre.

Sollte man vielleicht jede Klasse selber ihre Werte in einer eigenen Datei speichern lassen? Aber das wäre sicher wieder etwas zu viel des Guten?

Nathan

Übergib den Klassen den ostream/istream, die speichern/lesen dann einfach ihre Werte die sie brauchen.

IMHO sollte man alle Klassen völlig unabhängig von der Config-Klasse implementieren. Sonst werden deine Klassen überhaupt nicht wiederverwendbar in anderen Projekten.

stefkowa

Ich würde mich dann dazu entscheiden keine Klasse sondern zwei Funktionen zu schreiben. Eine zum Lesen und eine zum Schreiben der Werte.

Allerdings würde die Datei dann bei jeden Aufruf der Funktionen neu geöffnet, gelesen/geschrieben und wieder geschlossen werden. Ist das ein Punkt den man vernachlässigen kann? Oder gibt es noch einen ganz anderen Weg?

Nexus

stefkowa schrieb:

Bei einer Instanz der ConfigKlasse in der main, müsste ich diese dann an die WindowKlasse weiter reichen und von dieser an die anderen Klassen, die Werte aus der Config brauchen.

Selbst wenn ich die Instanz der ConfigKlasse erst in der WindowKlasse erzeuge, müsste ich sie immer noch an die anderen Klassen durchreichen. Auch durch Klassen durch, die sie selbst garnicht brauchen. Wäre sicher auch nicht das Wahre.

Der normale Weg, um Informationen weiter zu geben, ist nun mal über Funktionsparameter. Von daher finde ich das nicht so abwegig. Wenn du die Config-Klasse sehr weit durch irgendwelche Klassen durchreichen musst, solltest du dein Design überdenken. Eine Möglichkeit wäre auch, einfach die in der Klasse enthaltenen Attribute weiterzureichen...

Oder was genau ist das Problem dabei? Der Schreibaufwand?

Ich lade z.B. bei einem Spiel Konfigurationsdaten aus Lua-Skripten. Eine zentrale Klasse greift auf die einzelnen Attribute per String zu und packt sie in diverse Tabellen (als float , bool etc.), die dann wiederum an einzelne Spielkomponenten übergeben werden. Ich muss weder lange durchreichen, noch habe ich unnötige Abhängigkeiten (die Komponenten wissen nichts über Lua-Dateien). Und vor allem kommt das Design komplett ohne globale und statische Variablen aus.

KN4CK3R

Wie reagieren die einzelnen Spielkomponenten dann auf Configänderungen während der Laufzeit?

knivil

KN4CK3R schrieb:

Wie reagieren die einzelnen Spielkomponenten dann auf Configänderungen während der Laufzeit?

1.) Warum sollte sich die Konfiguration waehrend der Laufzeit aendern?
2.) Anscheinend ist es ein Lua-Script, dass einfach neu aufgerufen wird. Ist zu erwarten, dass es nicht allzuoft geschieht, dann kann auch die ganze Datei neu ausgefuehrt werden.

Ich sehe kein Problem darin, Settings beim Start der Anwendung zu laden und beim Beenden zu speichern.

Nexus

KN4CK3R hat möglicherweise Prototyping und schnelles Anpassen via Skript im Kopf. Oft werden Skripts unter anderem auch deswegen eingesetzt.

Momentan speichern die Komponenten nur Referenzen auf die zentralen Tabellen, d.h. wenn ich letztere ändere, werden die Änderungen implizit übernommen. Die Tabellen selbst sind Einträge in einer Map, und können nach Belieben neu geladen werden. Es wäre natürlich auch möglich, explizite Benachrichtigungsmechanismen (z.B. Callbacks, Dirty-Flag bei Cache) im Falle einer Änderung einzurichten.

asc

knivil schrieb:

1.) Warum sollte sich die Konfiguration waehrend der Laufzeit aendern?

Ich halte es nicht für unüblich, das man die Konfiguration innerhalb eines Programms ändern kann (Ich beziehe mich hier nicht nur auf Spiele).

Und bei großen Anwendungen ist es relativ aufwendig bei jeder Erweiterung der Konfiguration alle Funktionsaufrufe anzupassen. Dies ist ein Grund warum ich tatsächlich, trotz aller Einwände an einer solchen Stelle ein Singleton (oder vergleichbares) verwenden würde.

Wenn ich weiß das ich in nahezu 100% aller Fenster (in unserer Anwendung ist das so) Werte aus der Konfiguration benötige, würde alternativ nur helfen, das alle Fenster die Konfigurationsklasse als Parameter bekommen. In diesem Fall ist es tatsächlich eine globale Variable (schon aus historischen Gründen, da die VCL sehr stark mit eben diesen arbeitet).

antistatischaufgeladen schrieb:

Wenn dir das zu mühsam ist und dein Design schon so verkorst ist, dass das kaum umsetzbar ist, dann mach halt eine globale Variable vom Typ dieser Konfigurationsklasse.

Auf jeden Fall zu vermeiden ist: Singleton, statische Member.

Darf ich mal Fragen was an einer globalen Variable besser sein sollte, als an einem Singleton oder statischen Member? Aus meiner Sicht spielen alle drei in einer ähnlichen Liga.

knivil schrieb:

Ich sehe kein Problem darin, Settings beim Start der Anwendung zu laden und beim Beenden zu speichern.

Bei uns wird der Lesezugriff gecacht (In einem Circular Buffer), der Schreibzugriff aber relativ direkt gemacht (DB-Tabelle), da Teile dieser Einstellungen auch für andere Benutzer gelten. Wobei z.B. ein geöffnetes Fenster nur einmalig die Einstellungen einliest, und nicht auf Werteänderungen reagiert (wenn man selbiges später zur Laufzeit erneut öffnet, kann es unter Umständen aber schon mit neuen Einstellungen arbeiten).

knivil

Ich halte es nicht für unüblich, das man die Konfiguration innerhalb eines Programms ändern kann (Ich beziehe mich hier nicht nur auf Spiele).

Aber warum sollte ich dazu eine Datei aendern und einlesen.

asc

knivil schrieb:

Ich halte es nicht für unüblich, das man die Konfiguration innerhalb eines Programms ändern kann (Ich beziehe mich hier nicht nur auf Spiele).

Aber warum sollte ich dazu eine Datei aendern und einlesen.

a) Weil die Einstellungen Bestand haben sollen.
b) Weil nicht ein Absturz im Laufe des Betriebs die Einstellungen hinfällig machen soll (Es ist besonders schön, wenn man sich nach mehreren Stunden nicht mehr an die gemachten Einstellungen erinnert).

Nexus

asc schrieb:

a) Weil die Einstellungen Bestand haben sollen.
b) Weil nicht ein Absturz im Laufe des Betriebs die Einstellungen hinfällig machen soll (Es ist besonders schön, wenn man sich nach mehreren Stunden nicht mehr an die gemachten Einstellungen erinnert).

Das sind Gründe zum Speichern, nicht zum Laden...

Das erneute Laden kann für Prototyping sinnvoll sein, wenn Benutzer manuell Skripte ändern können. Oder für Plugins bzw. Updates, die man übers Netzwerk bekommt. Oder wenn der Benutzer ein bestehendes Profil auswählt.

Shade Of Mine

config ist ein Super Ding für einen Singleton.

Auch wenn hier viele gegen Singletons sind, das ist ein Paradebeispiel.

Alleine der Gedanke ein config Objekt überall weiterzureichen ist lächerlich.

Wenn man einen Schritt weiter Designed, dann hat man sowieso eine Manager Klasse die diverse Services anbietet, wie zB DB Zugriff, Config Werte, etc. Diese ist der Zentrale Singleton der von überall aus aufgerufen werden kann. Wenn man singleton nicht mag, nimmt man halt ein äquivalentes Pattern.

Aber das hier ist die Situation wo man eine "globale Variable" haben will.