Und genau darum sollte man automatisch ausschließlich die öffentlichen Dinge kopieren. (siehe TPersistent/TComponent und
DFM)
Maximal kann das Objekt noch über eine Methode für das Serialisieren spezieller interner Strukturen anbieten. (siehe TComponent.ReadState und TComponent.WriteState)
Wieso sollte die Serialisierung z.B. ein
Handle/Pointer des internen Feldes speichern, anstatt die Daten des öffentlichen Properties?
Genauso wie "standardmäßig" anderer Code gefälligst auf das Property zuzugreifen hat und nicht auf das private/interne Feld, so hat das auch eine Serialisierung gefälligst nicht zu tun, da sie garnicht wissen kann, wie man die internen Werte zu interpretieren hat.
Man macht ein Foto von deinem Häuserblock und will nun, ein Jahr später, den Zustand wiederherstellen:
* Sollen die nun einfach in deine Wohnung gehen und die Gardinen genauso auf-/zuziehen und die Lampen an-/ausschalten
* oder sollen sie dich fragen/dir sagen in welchem Fenster wie das Licht auszusehen hat?
Die wissen ja noch nichtmal welche Lampen man wo anschalten kann.
Sie können zwar der Glühbirne gern sagen "geh an", aber du weißt wo der Schalter sich versteckt und wie man ihn bedient.
Zitat:
Und wie macht man das bei so einem Objekt ohne auf die Felder zuzugreifen?
Entweder garnicht
, wenn das Objekt keine Serialisierung anbietet,
oder das Objekt bietet eine Funktion an, welche beim Serialisieren den Zustand von FState "freiwillig" rausgibt und beim Deserialisieren den Wert/Zustand wieder entsprechend herstellt.
Kopiere den Inhalt des
RAM eines Programms und später lade den Inhalt "blind" wieder in einen erstellten Prozess ... danach wird das Programm also wieder genauso aussehen und sich verhalten, wie vorher?
Ich glaube nicht.