44.1 Grundlagen und Begriffe

• 44.1 Grundlagen und Begriffe

Als Beans werden in Java eigenständige, wiederverwendbare Softwarekomponenten zum Aufbau von Applets und Applikationen bezeichnet. Obwohl sie nicht zwangsläufig eine für den Anwender sichtbare Oberfläche haben müssen, werden Beans doch typischerweise als grafische Komponenten zur Verfügung gestellt und können mit Hilfe eines GUI-Editors (GUI = Graphical User Interface) interaktiv zu komplexen Anwendungen zusammengesetzt werden.

Derartige GUI-Komponenten gibt es seit geraumer Zeit. Sie wurden auf dem PC mit Entwicklungsumgebungen wie Visual Basic oder Delphi populär und haben - beinahe noch stärker als rein sprachengetragene Konzepte - dazu beigetragen, die komponentenbasierte Softwareentwicklung einer breiten Masse von Entwicklern nahe zu bringen.

Beans gibt es seit der Version 1.1 des Java Development Kit. Während auch vorher schon wiederverwertbare Komponenten entwickelt werden konnten (wir haben das in Kapitel 33 am Beispiel einer selbstentwickelten 7-Segment-Anzeige demonstriert), wurde mit Einführung der Beans-Architektur eine Standardisierung vieler wichtiger Konzepte vorgenommen und so die Grundlage für die einheitliche Entwicklung von GUI-Komponenten gelegt.

Im Gegensatz zu den betriebssystem- und teilweise herstellerspezifischen Komponentenmodellen vieler Entwicklungssysteme steht mit den Beans eine plattformübergreifende Komponentenarchitektur zur Verfügung. Eine Bean von Hersteller A, die auf Betriebssystem B entwickelt wurde, sollte (wenn sie nicht aus anderen Gründen plattformabhängig ist) ohne Probleme in einer Entwicklungsumgebung des Herstellers C auf Betriebssystem D laufen und Bestandteil eines Java-Programms werden können, das schließlich auf Plattform E läuft.

Bevor wir uns den wichtigsten Eigenschaften einer Bean zuwenden, wollen wir uns kurz mit einigen grundlegenden Begriffen vertraut machen.

Bei der Entwicklung einer Anwendung mit grafischen Komponenten wird zweckmäßigerweise zwischen Designzeitpunkt und Ausführungszeitpunkt unterschieden. Beide bezeichnen eigentlich Zeiträume und stehen für die beiden unterschiedlichen Phasen der Entwicklung einer Anwendung und ihrer späteren Ausführung. Zum Designzeitpunkt werden die Komponenten in einem grafischen Editor des Entwicklungswerkzeugs ausgewählt, in einem Formular plaziert und an die Erfordernisse der Anwendung angepaßt. Diesen Editor wollen wir fortan als GUI-Designer bezeichnen, synonym werden aber auch Begriffe wie Grafik-Editor, GUI-Painter usw. verwendet.

Ein großer Teil der bei den Beans realisierten Konzepte spielt nur für den Designzeitraum eine Rolle. Spielt dieser keine Rolle (beispielsweise weil die Komponenten nicht in einem GUI-Designer, sondern - wie in diesem Buch bisher stets gezeigt - per Source-Code-Anweisungen eingebunden und konfiguriert werden), verlieren Beans einiges von ihrer Nützlichkeit, und herkömmliche Techniken der Wiederverwendung in objektorientierten Programmen können an ihre Stelle treten.

Hinweis

Wir wollen uns die wichtigsten Eigenschaften von Beans zunächst überblicksartig ansehen:

1. Eine Bean wird im Programm durch ein Objekt (also eine instanzierte Klasse) repräsentiert. Das gilt sowohl für den Designzeitpunkt, bei dem es vom GUI-Designer instanziert wird, als auch für den Ausführungszeitpunkt, bei dem die Anwendung dafür verantwortlich ist, das Objekt zu konstruieren. Eine Bean benötigt dazu notwendigerweise einen parameterlosen Konstruktor.
2. Sie besitzt konfigurierbare Eigenschaften, die ihr Verhalten festlegen. Diese Eigenschaften werden ausschließlich über Methodenaufrufe modifiziert, deren Namen und Parameterstrukturen genau definierten Designkonventionen folgen. Damit können sie vom GUI-Designer automatisch erkannt und dem Entwickler in einem Editor zur Auswahl angeboten werden.
3. Eine Bean ist serialisierbar und deserialisierbar. So können die zum Designzeitpunkt vom Entwickler vorgenommenen Einstellungen gespeichert und zum Ausführungszeitpunkt rekonstruiert werden. (Serialisierung wurde in Kapitel 41 behandelt).
4. Eine Bean sendet Events, um registrierte Listener über Änderungen ihres internen Zustands oder über sonstige wichtige Ereignisse zu unterrichten.
5. Einer Bean kann optional ein Informations-Objekt zugeordnet werden, mit dessen Hilfe dem GUI-Designer weitere Informationen zur Konfiguration übergeben und zusätzliche Hilfsmittel, wie spezialisierte Eigenschafteneditoren oder Konfigurationsassistenten, zur Verfügung gestellt werden können.

Werden diese Konventionen eingehalten, kann der GUI-Designer die Bean zum Designzeitpunkt automatisch untersuchen (dieser Vorgang wird als Introspection bezeichnet) und dem Entwickler alle öffentlichen Eigenschaften, Methoden und Ereignisse menügesteuert anbieten. Die Eigenschaften werden dabei üblicherweise in einem Property Sheet (oder Eigenschaftenfenster) angeboten und erlauben es dem Entwickler, den Zustand der Bean interaktiv zu verändern. Da eine Bean serialisierbar ist, kann der GUI-Designer alle Design-Anpassungen speichern und dem Programm zum Ausführungszeitpunkt zur Verfügung stellen.

Bei manchen GUI-Designern können Beans darüber hinaus grafisch miteinander verbunden werden, um zu symbolisieren, daß bei Auftreten eines vorgegebenen Ereignisses in Bean A eine bestimmte Methode in Bean B aufgerufen wird. Der GUI-Designer erzeugt dann eine geeignete Adapterklasse und generiert den Code zum Aufruf der Methode. Manche GUI-Designer erlauben es zusätzlich, den generierten Code zu modifizieren und so bereits wesentliche Teile der Programmlogik im Designer zu erstellen.