protonmw (Marc) hat geschrieben:da ich wie gesagt erst Einsteiger bin, verstehe ich die Serialisierung noch nicht ganz. Kannst du das bitte nochmal erläutern? (Für jemanden der eher auf µC-Basis mit Bits und Bytes wirbelt
)
Vielleicht hole ich besser noch einen Schritt weiter aus. Wenn man sich zum ersten Mal mit OO beschäftigt, begegnet einem die Klasse als zentrales Gestaltungselement. Und man erfährt, Klassen fassen Eigenschaften und Verhalten zusammen. Und das findet man einleuchtend. Aber dann denkt man nach und erkennt, ganz so einfach ist es doch nicht, denn die entscheidende Frage wird nicht beantwortet: Wie komme ich zu meinen Klassen?
Ohne jetzt ganze Entwurfstechnologien überflüssig machen zu wollen, aber bei einfachen Aufgabenstellungen hilft schon das Beschreiben der Aufgabe und das Ausformulieren von Lösungsgedanken. Man wird Sätze mit Substantiven und Verben bilden. Schaut man genauer hin, könnten sich hinter den Substantiven die Namen von Klassen verbergen und hinter Verben die Namen von Methoden. Hinter Adjektiven könnten Eigenschaften von Klassen stecken. Bei unserem überschaubaren Projekt wird mit Sicherheit sehr früh das Substantiv "Telegramm" genannt werden, ein potentieller Kandidat für eine Klasse. Und eine Eigenschaft wäre der im Telegramm enthaltene Mess- oder Anzeigewert (der nicht notwendigerweise als Adjektiv auftauchen muss). Verhalten per Verb finden wir eher: Senden und empfangen.
Damit ist unsere Telegramm-Klasse grob umrissen. Sie enthält einen Wert (Eigenschaft) und man soll das Telegramm senden oder empfangen können (Verhalten).
Sockets gibt es auch noch. Wieder ein Kandidat für eine Klasse. Der Socket hat auch wieder Eigenschaften, z.B verbunden oder nicht und mit wem. Und natürlich Verhalten. Der Socket soll ebenfalls senden und empfangen können, und zwar zum und vom anderen Socket. Was soll er vesenden oder empfangen? Telegramme. Unsere Telegramme. Die in Klassen.
Die Grundfunktion unseres Socket ist vorgegeben, durch das API. Und das kennt keine Telegramm-Klassen, das kennt nur Bytes.
Sollen wir also unsere gerade gefundene Telegramm-Klasse mit der doch praktischen Eigenschaft "Wert" wieder aufgeben und uns an diese wenig anschaulichen Bytes anpassen? Unschön. Und da andere schon vorher auf das Problem gestoßen sind, dass die anschaulichere und praktische Repräsentation von Daten in Klassen nicht unbedingt kompatibel zu dem ist, was über lange Drähte tatsächlich übertragen wird, kam man auf die Idee einer zweckgerichteten, aber ein wenig abstrahierten Wandlung. Diese hier nennt man Serialisierung (bzw. Deserialiserung in Umkehrrichtung). Bei der Serialisierung werden die wahlfrei zugreifbaren Eigenschaften des Objekts einer Klasse in eine Datensequenz verwandelt, auf die nur seriell zugegriffen werden kann. Dazu kann man wieder eigene Klassen benutzen benutzen. Die nennt man dann z.B. Stream.
Das anfangs genannte und angestrebte Verhalten unserer Telegramm-Klasse, sich selbst versenden oder empfangen zu können, läuft also darauf hinaus, die eigenen Eigenschaften in ein vom weiterem Transport vorgegebenes sequentielles Format zu wandeln. Genau das machen wir mit besagter Serialisierung.
Und durch die Hintertür haben wir gleichzeitig ein weiteres nicht unwesentliches Merkmal der OO mit eingeführt: Das der der Abstrahierung. Wir können nachvollziehen, dass die Umwandlung von seriellen Bytes in wahlfrei zugreifbare Eigenschaften notwendig ist. Wir nennen es abstrakt "Serialisierung" und können das notwendige dafür in sogar in eine eigene Klasse zusammenfassen, jenen Stream.
Ich hoffe, mit dieser Erläuterung wird das Vorgehen klarer.