Grundtechniken

Generell stellt sich zunächst die Frage nach dem Medium, in dem Objekte länger leben bzw. bewegt werden können. Statt konkret an Dateisysteme oder gar Datenbanken zu denken, empfiehlt es sich, die notwendige Grundeigenschaft zu verlangen, die für alle weiteren Varianten die Voraussetzung bildet:

Ein Objekt ist genau dann persistent, wenn es in eine Sequenz von Bytes verwandelt werden kann und umgekehrt aus der Sequenz von Bytes wieder ein Objekt erzeugt werden kann, das semantisch identisch zum Ausgangs-Objekt ist.^6.2

Wenn ein Objekt einmal in eine Bytesequenz verwandelt worden ist, kann es anschließend beliebig in Dateien und Datenbanken abgelegt oder über das Netzwerk zu anderen Prozessen und Adreßräumen übermittelt werden. Dies wird insbesondere durch eine geeignete Abstraktion für Bytesequenzen erleichtert, wie sie z.B. durch Streams bei der Ulmer Oberon-Bibliothek gegeben ist.

Im Umfeld objekt-orientierter Programmiersprachen liegt es nahe, die Objekte selbst die Verantwortung für die Konvertierungen übernehmen zu lassen. Allerdings ergeben sich dabei zwei Probleme:

• Angenommen, persistente Objekte hätten die Methoden Read und Write. Der Aufruf von Write ist kein Problem - jedoch: Wie soll eine Methode Read aufgerufen werden, wenn das Objekt noch nicht da ist und nur als Bytesequenz vorliegt?

• Ein kleineres Problem ergibt sich dadurch, daß an einem Objekt beliebig viele Module mit privaten Informationen beteiligt sein können. Entsprechend werden bei den Konvertierungen kooperative Mechanismen benötigt, die alle interessierten Parteien einschließen.

Das zweite Problem kann bei klassischen Programmiersprachen durch die Verpflichtung zum Aufruf der übergeordneten Methode (Super-Methode) gelöst werden oder allgemein durch entsprechende Registrierungstechniken. Das erste und entscheidende Problem läßt sich nur durch die Einführung von Typinformationen lösen und setzt damit die Existenz von Typen als 1st class objects voraus.^6.3

Für den Fall, daß die Programmiersprache Typen nicht direkt als Objekte zugänglich macht, reicht es insbesondere nicht aus, beim Einlesen nur genügend Speicher für eine Kopie zu organisieren und die Bytesequenz zurück in den Speicher zu kopieren. Denn hierbei würde die interne Typinformation verloren gehen, für die kein portabler Zugang zur Verfügung steht (sonst hätten wir Typen als 1st class objects). Somit müssen die Objekte beim Einlesen wieder auf die gewohnte Weise kreiert werden, und da der NEW-Operator den Typen auf statisch festgelegte Weise direkt oder indirekt erhält, kann dies nicht auf allgemeine Weise geschehen, sondern nur über für jeden persistenten Typ registrierte Konstruktoren.

Abbildung 6.1: Darstellung eines Objekts in einer Bytesequenz

Um dies zu erreichen, ist es notwendig, nicht nur die Objektdaten zu sichern, sondern auch noch die Typinformation (siehe Abbildung 6.1). Dabei ist es am geeignetsten, einen global eindeutigen Typnamen in Form einer Zeichenkette zu verwenden.

Somit werden bei einer reinen Bibliothekslösung folgende Methoden benötigt:

Create:

Eine Methode in Abhängigkeit der Typinformation, die ein entsprechendes Objekt kreiert und initialisiert.

Read:

Konvertierung einer Bytesequenz in den Inhalt eines Objekts, das bereits existiert.

Write:

Konvertierung eines Objekts in eine Sequenz von Bytes.

Theoretisch können Create und Read zusammengelegt werden - dann wären jedoch keine kooperativen Lösungen möglich, wenn mehr als eine Partei private Daten zu dem Objekt unterhält.

Mit der im Rahmen einer Bibliothek realisierten Persistenzeigenschaft würde dann folgender manuell zu programmierender Verwaltungsaufwand notwendig werden:

• Jedes Modul (bzw. Klasse) muß zu seiner Initialisierungszeit seine persistenten Datentypen registrieren zusammen mit den zugehörigen Methoden Create, Read und Write. Bei Abstraktionen ohne eigene Datenstrukturen werden keine Methoden benötigt.

• Wenn Typen als 1st class objects im Rahmen der Bibliothek realisiert sind, dann müssen neu kreierte Objekte mit den zugehörigen Typen verbunden werden.