Java Reference
In-Depth Information
■
8 . 4 So ware-Werkzeuge
Für die Entwicklung einer aus Beans bestehenden Anwendung braucht man nicht notwen-
digerweise eine visuelles So ware-Werkzeug (Builder Tool). Es ist durchaus möglich, ein
Programm zu schreiben, das Bean-Objekte erzeugt, deren Eigenscha en mit Hilfe der Set-
ter-Methoden verä ndert und die Bean-Objekte entsprechend miteinander verknüp , indem
zum Beispiel ein Bean-Objekt bei einem anderen Bean-Objekt als Listener angemeldet wird.
Eine ganz wesentliches Merkmal von Java Beans ist aber die Vorstellung, dass mit Hilfe
eines So ware-Werkzeugs visuell und interaktiv eine Anwendung aus vorhandenen Bau-
steinen zusammengebaut werden kann, ohne dass man dafür programmieren (können)
muss. Es gibt zwei Sorten von Beans, welche von diesen Werkzeugen unterstützt werden:
!
Die erste Bean-Sorte sind solche Beans, die als Interaktionselemente in einer grafi schen
Benutzeroberfl äche vorkommen. Dazu zählen zum einen die Swing-Klassen wie JButton,
JSlider usw., die von den Werkzeugen direkt als Bean-Klassen verwendet werden können.
Zum anderen können dies aber auch selbst entwickelte Klassen sein, wenn diese aus
JPanel, JButton oder einer anderen geeigneten Klasse abgeleitet sind. Mit Hilfe des Buil-
der-Werkzeugs lässt sich damit eine Oberfl äche mit „Drag and Drop“ zusammenstellen.
Das Builder Tool hat somit u. a. die Funktionalität eines sogenannten GUI Builders (GUI:
Graphical User Interface).
!
Die zweite Sorte von Beans sind solche, die keine Interaktionselemente darstellen. Wird
ein Objekt davon erzeugt und auf die Oberfl äche gezogen, so zeigt das So ware-Werkzeug
ein Rechteck mit entsprechender Beschri ung oder, falls für die Bean-Klasse ein Icon
bereitgestellt wurde (s. Abschnitt 8.3), das Icon an.
Eine zusammengestellte Anwendung kann nur aus einer der beiden Bean-Sorten bestehen
oder aus beiden. Durch Refl ection lassen sich die Attributwerte anzeigen und entsprechend
ändern, was sich bei Beans der ersten Sorte in der Regel unmittelbar auf ihr Aussehen aus-
wirkt (die Änderung des Textattributs eines JLabel-Objekts sieht man unmittelbar). Ebenso
kann man über Refl ection erkennen, welche Listener an einem Bean angemeldet werden
können. Durch das Ziehen von Verbindungslinien kann ein vorhandenes Bean-Objekt als
Listener bei einem anderen Bean-Objekt angemeldet werden, falls das erste Bean-Objekt die
entsprechende Schnittstelle implementiert. Falls dies nicht der Fall ist, kann das So ware-
Werkzeug unter Umstä nden den dazu fehlenden Code automatisch generieren. Das Beispiel
hierzu, das in der Dokumentation der Firma Sun zu Java Beans vorkommt, ist eine Anwen-
dung, die aus drei Bean-Objekten besteht, die alle zu der ersten Bean-Sorte gehören (die also
alle in einem Fenster einer grafi schen Benutzeroberfl äche vorkommen können): Das erste
Bean ist ein Objekt einer aus JPanel abgeleiteten Klasse, die eine Animation eines Jongleurs
darstellt. Diese Klasse hat Methoden zum Starten und Anhalten der Animation. Die beiden
anderen Bean-Objekte sind Objekte der Klasse JButton. Es lässt sich interaktiv die Beschrif-
tung der JButtons verä ndern. Der eine JButton bekommt die Beschri ung „Start“ und der
andere „Stopp“. Durch das Ziehen einer Linie von einem JButton auf das Animations-Bean
können die beiden miteinander verbunden werden. Zwar implementiert das Animations-
Bean nicht die Schnittstelle ActionListener, um das Animations-Bean an einem JButton als
ActionListener anzumelden. Aber das So ware-Werkzeug fragt, welche Methode des Ziel-
Beans (in diesem Fall des Animations-Beans) beim Klicken des Buttons aufgerufen werden
soll. Gibt man für den Start-Button die Methode zum Starten der Animation und für den
