E
Also wenn man sich z.B. Mal Qt anschaut, gibt es dort eine Settings-Klasse.
Dort wird es so geregelt, dass Du Gruppen hast, diese Gruppen enthalten wiederum eine beliebige Menge von benannten Attributen, deren Typ alles Mögliche sein kann (QVariant, bei Boost z.B. boost::any).
Die Zuordnung von jedem einzelnen Objekt zu den jeweiligen Daten ist hartverdrahtet, d.h. man serialisiert nicht einfach ein Fenster, sondern man erstellt eben manuell die Gruppe "MainWindow" und gibt der die Attribute "xPosition, yPosition" - was auch immer.
Es ist ja auch nicht sinnvoll von jedem einzelnen Element auf dem Fenster alle Eigenschaften zu speichern, da solltest Du stark selektieren.
Meine Idee wäre daher gar kein generelles Konzept fürs Serialisieren zu entwickeln (im Sinne davon, dass es generisch für alle Klassen funktioniert), sondern einfach nur eine große Klasse zu haben, der man sagen kann "speicher bitte diese Zahl/diesen String unter dem Namen" und fürs Laden wieder zu interpretieren. Das wäre dann die Zugriffsschicht von Serializer <-> UI.
Die Speicherung kann dann unterschiedlich erfolgen. Üblich ist unter Windows ja die Registry, Mac und Linux haben da wiederum andere Möglichkeiten - das ist also nicht portabel bzw. muss je nach BS neu entwickelt werden. Und wenn man es dann in einer Datei (z.B. ini oder xml) speichert, muss halt herausgefunden werden wie der jeweilige Benutzerordner auf dem Betriebssystem ist, in dem ein Nicht-Admin-Programm Schreib/Lesezugriff hat.
Ich würde also erstmal schauen, ob das UI-Framework etwas Derartiges anbietet. Falls nicht, würde ich nach einer externen LIB schauen. Falls es da nichts Passendes gibt, würde ich es selbst schreiben, dann vermutlich über eine Datei und dort so etwas Ähnliches wie eine Gruppenlösung erzeugen.
Ich weiß nicht, wie es C# handhabt, aber wenn man solche Eigenschaften wirklich von jedem Objekt speichern muss, setzt das Voraus, dass man auch jedes Objekt befüllen muss - und das heißt, dass man es nicht normal erzeugen kann, sondern die Erzeugung abstrahieren muss, etwa über eine Factory o.ä. Das bläht das Projekt konzeptionell also auf, obwohl man nur für einen Bruchteil der Objekte überhaupt etwas speichern muss.
Möchte man ein Default-Schreib/Lese-Verhalten für eine bestimmte Klasse erzeugen, erscheint es mir ebenfalls gut operator<<, >>, read, write zu überschreiben, dann aber natürlich von einer Instanz aus zu verwenden, die eben weiß, was gespeichert werden muss. Die muss dann auch dafür sorgen, dass bei Programmstart alle Daten in die entsprechenden Objekte gefüllt werden.
Hängt halt jetzt von den Details ab. So viel muss man imo meist gar nicht speichern und es bei Programmstart neu laden.
