From 33613a85afc4b1481367fbe92a17ee59c240250b Mon Sep 17 00:00:00 2001 From: Sven Eisenhauer Date: Fri, 10 Nov 2023 15:11:48 +0100 Subject: add new repo --- .../hjp5/html/k100280.html | 193 +++++++++++++++++++++ 1 file changed, 193 insertions(+) create mode 100644 Master/Reference Architectures and Patterns/hjp5/html/k100280.html (limited to 'Master/Reference Architectures and Patterns/hjp5/html/k100280.html') diff --git a/Master/Reference Architectures and Patterns/hjp5/html/k100280.html b/Master/Reference Architectures and Patterns/hjp5/html/k100280.html new file mode 100644 index 0000000..dd52ee5 --- /dev/null +++ b/Master/Reference Architectures and Patterns/hjp5/html/k100280.html @@ -0,0 +1,193 @@ + + + +Handbuch der Java-Programmierung, 5. Auflage + + + + + + + + + +
 Titel  + Inhalt  + Suchen  + Index  + DOC  +Handbuch der Java-Programmierung, 5. Auflage +
 <<  +  <   +  >   + >>  + API  +Kapitel 44 - Beans +
+
+ + + + +

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 platziert und an die Erfordernisse der Anwendung +angepasst. 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, dass 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. +

+ + + +
 Titel  + Inhalt  + Suchen  + Index  + DOC  +Handbuch der Java-Programmierung, 5. Auflage, Addison +Wesley, Version 5.0.1 +
 <<  +  <   +  >   + >>  + API  +© 1998, 2007 Guido Krüger & Thomas +Stark, http://www.javabuch.de +
+ + + -- cgit v1.2.3