Java Reference
In-Depth Information
und boolean besitzt, dann werden bei der Serialisierung die Werte dieser Attribute (z. B.
1147 und false) gespeichert. Da auch der Klassenname gespeichert wird, lässt sich mit Hilfe
der sogenannten Deserialisierung aus diesen Daten ein neues Objekt der Klasse X erzeu-
gen, dessen Attributen die abgespeicherten Werte zugewiesen werden, so dass zwar ein
neues Objekt entsteht, dessen Inhalte aber gleich sind wie beim Originalobjekt. Das Ganze
funktioniert rekursiv: Ist der Typ eines Attributs kein primitiver Datentyp wie int und boo-
lean, sondern eine Referenztyp (d. h. eine Klasse oder Schnittstelle), so wird beim Serialisie-
ren der Referenz nachgegangen und das Objekt, auf das diese Referenz verweist, wird eben-
falls serialisiert. Dieser Prozess kann sich über beliebig viele Stufen erstrecken. Dabei
werden Objekte, die schon bearbeitet wurden, erkannt; diese werden dann nicht nochmals
serialisiert. Somit wird ein Objekt nur einmal serialisiert, auch wenn mehrere serialisierte
Objekte eine Referenz darauf besitzen. Insbesondere kommt es damit bei zyklischen Refe-
renzfolgen nicht zu einer Endlosschleife bei der Serialisierung. Bei der Deserialisierung
werden Kopien der Objekte erzeugt und die „Verdrahtung“ der Objekte wird wieder genau
so hergestellt, wie sie ursprünglich war. Um ein Objekt mit Hilfe der Java-Serialisierung
serialisieren zu können, muss seine Klasse die Schnittstelle Serializable implementieren.
Serializable ist eine leere Schnittstelle (sie besitzt also keine Methoden, die implementiert
werden müssen). Serializable ist lediglich eine sogenannte Markierungsschnittstelle, mit
der man explizit kennzeichnen muss, dass Objekte dieser Klasse serialisierbar sein sollen.
Aus den bisherigen Ausführungen ergibt sich, dass es für eine erfolgreiche Serialisierung
nicht genügt, wenn die Klasse eines Objekts die Schnittstelle Serializable implementiert,
sondern dies muss in rekursiver Weise für alle Objekte gelten, auf die das zu serialisierende
Objekte Referenzen hält. Will man ein Attribut von der Serialisierung explizit ausnehmen,
so kann man dieses durch das Java-Schlüsselwort transient entsprechend kennzeichnen.
So viel als kurzer Einschub zum Thema Serialisierung. Kommen wir nun zurück zu den
Java Beans: Aufgrund der eingangs dieses Abschnitts geschilderten Grundidee zum Einsatz
von Java Beans ergeben sich folgende Eigenscha en für Bean-Klassen:
!
Eine Bean-Klasse muss weder eine vorgegebene Schnittstelle implementieren noch aus
einer speziellen Klasse abgeleitet sein. Bean-Objekte sind also POJOs (Plain Old Java
Objects).
!
Damit ein So ware-Werkzeug durch interaktive Angabe einer Bean-Klasse ein Bean-
Objekt erzeugen kann, sollten Bean-Klassen einen parameterlosen Konstruktor besitzen.
!
Um nach dem Zusammenklicken einer Anwendung aus Bean-Komponenten die Objekte
abspeichern zu können, sollten alle Bean-Klassen die leere Schnittstelle Serializable (aus
dem Package java.io) implementieren. Wenn die Bean-Klassen Attribute besitzen, die auf
andere Objekte (Beans oder Hilfsobjekte) verweisen, so sollten die Klassen dieser Objekte
ebenfalls Serializable implementieren, oder die Attribute müssen als transient gekenn-
zeichnet sein. Dies gilt in rekursiver Form für alle referenzierten Objekte.
!
Wenn es möglich sein soll, die Attributwerte eines Bean-Objekts interaktiv über ein So -
ware-Werkzeug anzuzeigen und zu verä ndern, ist es ratsam, für diese Attribute entspre-
chende Getter- und Setter-Methoden in der Bean-Klasse bereitzustellen.
!
Das Zusammenspiel unterschiedlicher Bean-Objekte kann in jeder beliebigen Form erfol-
gen. Wenn aber Bean-Objekte mit den Bean-spezifi schen So ware-Werkzeugen „verdrah-
tet“ werden sollen, dann müssen die Beans gemäß des Beobachter-Entwurfsmusters inter-
agieren. Das heißt, dass es beobachtbare Objekte (auch Ereignisquellen genannt) und
