Java Reference
In-Depth Information
!
Zu E2: Die Kopplung der Java-Beans-Komponenten erfolgt zwar nicht über ein Komponen-
ten-Framework zur Laufzeit, aber vor der Ausführung über ein interaktives So ware-
Werkzeug. Die Objektkonfi guration wird abgespeichert und zur Laufzeit wieder herge-
stellt. Somit lässt sich auch für Java Beans ein Kopplungsmechanismus identifi zieren. Das
Austauschen von Komponenten ist allerdings nur in der Konfi gurationsphase, nicht aber
zur Laufzeit möglich.
!
Zu E3: Die in der Konfi gurationsphase abgespeicherten Objektdaten werden zur Laufzeit
eingelesen. Auf diese Art werden durch die Deserialisierung die Komponentenobjekte
quasi automatisch und ohne Zutun des Anwendungsprogrammierers erzeugt. Die Reali-
sierung eines echten Lebenszyklus ist für die Komponenten nicht zu erkennen. Statt den
Diensten eines Komponenten-Frameworks gibt es die Funktionen, die von den unterschied-
lichen So ware-Werkzeugen bereitgestellt werden. Somit gibt es auch in diesem Punkt
eine zumindest teilweise Übereinstimmung mit den Vorgaben.
!
Zu E4: Mit Hilfe der BeanInfo-Klassen kann man für die Bean-Klassen explizit festlegen,
welche Eigenscha en, Ereignisse und Methoden über das So ware-Werkzeug angezeigt
werden. Dies kann man durchaus als eine explizite Angabe dessen sehen, was eine Kom-
ponente zur Verfügung stellt. Fehlen diese Angaben, so lassen sie sich automatisch mit
Hilfe von Refl ection gewinnen. Was eine Komponente benötigt, wird allerdings nicht
explizit angegeben.
Wie bereits erwähnt, passen die Vorgaben aus Kapitel 7 nicht so ganz zu Java Beans. Mit
einigen Umdeutungen wurde es aber doch möglich, so viele Übereinstimmungen zwischen
den charakteristischen Merkmalen der Java Beans und den Vorgaben zu fi nden, dass das
Konzept von Java Beans — wenn auch mit Vorbehalt — als Komponentensystem eingestu
werden kann und die Besprechung von Java Beans in diesem Buch gerechtfertigt erscheint.
