Laden...

Untersch. Behandlung der Objektdaten bzgl. Modifizierer bei Serialisierung in den versch. Formaten

Erstellt von MichiM vor 19 Jahren Letzter Beitrag vor 18 Jahren 4.851 Views
M
MichiM Themenstarter:in
14 Beiträge seit 2004
vor 19 Jahren
Untersch. Behandlung der Objektdaten bzgl. Modifizierer bei Serialisierung in den versch. Formaten

Hallo C#-Freunde,

hat hier jemand eine Ahnung, warum .NET die einzelnen Serialisierungsformate bzgl. der Zugriffsmodifizierer bei den Daten unterschiedlich behandelt?
Na gut, weil die Klassen halt so geschrieben sind, ok. 🙂 Aber hat das einen tieferen Sinn?

Warum werden bei der XML- und SOAP-Serialisierung nur diejenigen Daten serialisiert, die als public deklariert sind? Warum sind dagegen bei der binären Serialisierung die Zugriffsmodifizierer dann wieder egal?

MfG
Michi

M
MichiM Themenstarter:in
14 Beiträge seit 2004
vor 19 Jahren

Könnte es vielleicht damit zusammenhängen, dass man XML und SOAP ja eher zur Kommunikation mit anderen Anwendungen verwendet, also von daher auch normalerweise Daten serialisiert haben will, die die anderen was angehen, also nicht private sind, während man bei der binären ja für sich selber serialisiert (z.B. Konfiguration bei Programmende) und da alles serialisiert haben will? Eine andere Erklärung find ich nicht....

49.485 Beiträge seit 2005
vor 18 Jahren

Hallo MichiM,

ich betätige mich mal als Archäologe, weil ich das Thema spannend finde.

Serialization is the process of converting the state of an object into a form that can be persisted or transported.

Die entscheidende Frage ist, was man als Zustand (state) des Objekts ansieht. Je nachdem welche Sicht man dabei einnimmt, kommt man zu unterschiedlichen Ergebnissen.

Aus der Sicht des Benutzers einer Klasse wie beispielsweise Datum mit den Properties Tag, Monat und Jahr, bestimmt der Wert dieser drei Properties den Zustand des Objekts. Was anderes kann man von außen ja auch nicht sehen. Wir könnten das also den äußeren Zustand nennen. Das ist auch der Zustand, den die XML-Serialisierung verwendet, indem sie die Werte der Properties ausliest; leider mit einer wesentlichen und unangenehmen Einschränkung. Und das liegt an der Deserialisierung:

Complement of serialization is deserialization, which converts a stream into an object.

Da beim Auslesen des Zustandes die Properties verwendet werden, müssen sie auch für das Zurückschreiben verwendet werden. Sonst wäre das Ganze halbherzig und asymmetrisch. Deshalb werden schon beim Serialisieren nur die Properties ausgelesen, für die neben einem öffentlichen Getter auch ein solcher Setter existiert.

Damit ist aber - so schön der Gedanke ist, die Kapselung der Objekte nicht zu verletzen und den äußeren Zustand zu verwenden - die XML-Serialisierung in meinen Augen fast immer unbrauchbar. Man denke nur an immutable Objekte wie Color, die sich deshalb (standardmäßig) nicht XML-Serialisieren lassen. Anm.: Die Basistypen wie char, int, String u.ä., die ja auch immutable sind, können nur deshalb standardmäßig xml-serialisiert werden, weil die XmlSerializer-Klasse diese intern extra behandelt.

Weitere Schwierigkeiten gibt es, wenn eine Klasse Properties für verschiedenen Repräsentationen desselben Zustandes zur Verfügung stellt. Wenn beispielsweise die Klasse Punkt (zweidimensionale Koordinaten) nicht nur die Properties X und Y (kartesische Koordinaten) zur Verfügung stellt, sondern auch R und Phi (Polarkoordinaten). Zum einen werden hier Informationen redundant abgefragt, gespeichert und gesetzt, zum anderen kann es zu Rundungsfehlern führen, je nachdem in welcher Reihenfolge die Properties verarbeitet werden.

Man kann sich beliebige weitere Beispiele vorstellen, bei der die Benutzung von Properties Probleme macht, z.B. wenn Prüfungen in denselben fehlschlagen, weil die korrekte Reihenfolge des Setzens durch die (standardmäßige) Deserialisierung nicht eingehalten wird.

Aus der Sicht des Implementierers der Klasse Datum sieht die ganze Sache anderes aus. Für ihn ist der Zustand des Objekts gegeben durch die Felder (Exemplarvariablen) des Objekts. Das könnten z.B. die Anzahl der Sekunden seit dem 01.01.1970 sein, also eine ganz andere Repräsentation als die, die der Benutzer der Klasse sieht.

Kleiner Einschub: In meinen Augen sollten alle Felder private oder protected sein, aber nie public. Will man, dass ein Feld eigentlich auch nach außen zur Verfügung steht, dann stellt man stattdessen eine entsprechende public Property zur Verfügung, lässt das Feld selbst aber private oder protected.

Die Felder kann man also nur von innen sehen. Wir könnten das also den inneren Zustand nennen. Das ist auch der Zustand, den die binäre Serialisierung verwendet, indem sie die Werte der Felder ausliest; da Felder (Variablen) jedoch immer auch schreibbar sind, entstehen hier keine Einschränkungen wie bei der XML-Serialisierung.

Genau genommen, gibt es auch bei Feldern Einschränkungen der Schreibbarkeit, aber diese manchen keine Probleme. Bei readonly Feldern entstehen deshalb keine Einschränkungen, weil die Deserialisierung einen Konstruktor verwendet. Dort sind auch readonly-Felder schreibbar. Und const Felder sind eigentlich gar keine Felder sondern Konstanten, die ohnehin ihren festen Wert haben und weder serialisiert noch deserialisert werden müssen.

Zu guter Letzt kann man sich noch fragen, warum gerade die Xml-Serialisierung den äußeren Zustand und warum die die binäre Serialisierung den inneren Zustand verwendet? Ich denke, das liegt daran, dass eine Xml-Datei auch menschenlesbar ist und damit dem Benutzer der Klasse zugänglich. Um die Kapselung nicht zu verletzen, darf dieser natürlich nur den äußeren Zustand sehen. Das Ergebnis der binären Serialisierung ist jedoch ohne Kenntnis des inneren Aufbau des Objekts ohnehin nicht verständlich. Deshalb kann hier getrost der innere Zustand verwendet werden.

herbivore

Suchhilfe: Auch wenn es nur gut 600 Worte sind spendiere ich mal das Stichwort 1000 Worte.
innerer Zustand, äußerer Zustand