Java Reference
In-Depth Information
Dateien wie z.B. serialisierten Java-Objekten, Dateien mit Meldungstexten in unterschied-
lichen Landessprachen, Bildern, Audio- und Videodateien usw. Diese Dateien werden in der
Regel zu einer einzigen Archiv-Datei zusammengepackt (typisch sind die Endungen .jar
oder .zip, es kommen aber auch andere Endungen vor wie z. B. .war, .ear oder .apk). Wie die
gepackte Datei aussehen muss, wird vom spezifi schen Komponentensystem vorgegeben. Zu
diesen Vorgaben, die das sogenannte Komponentenmodell darstellen, gehört z. B. auch, wie
die Einstiegsklasse aussehen muss (ob sie z. B. eine bestimmte Schnittstelle implementie-
ren oder aus einer bestimmten Klasse abgeleitet sein muss). Das Komponentenmodell kann
neben strengen Vorgaben auch Möglichkeiten anbieten, die eine Komponenten nutzen
kann, aber nicht muss (z. B. dass Methoden mit bestimmten Annotationen gekennzeichnet
werden können, aber nicht müssen). Eine Komponente bildet eine Installationseinheit,
wobei in der Regel der Einsatz nur eines Teils einer Komponente keinen Sinn macht oder
technisch nicht durchführbar ist. Es ist möglich, dass mehrere Versionen einer Komponente
in einem laufenden System gleichzeitig existieren.
E2: Es existiert ein Mechanismus zur Kopplung von Komponenten durch ein
Komponenten-Framework. Dadurch wird das Modularitätsprinzip unterstützt,
so dass Komponenten leicht hinzugefügt, entfernt und ausgetauscht werden
können (nach Möglichkeit im laufenden Betrieb).
Komponenten können kombiniert werden, wobei die Kombinationsvorschri nicht in den
Komponenten explizit ausprogrammiert sein soll, sondern außerhalb des Komponenten-
Codes durch ein Komponenten-Framework erbracht wird. Beispielsweise können Kompo-
nenten grafi sch-interaktiv durch das „Strippenziehen“ mit der Maus kombiniert werden
(z. B. Java Beans). Eine andere Form ist die Festlegung der Beziehungen zwischen Kompo-
nenten in Form einer XML-Datei oder durch Annotationen (s. Abschnitt 3.6 über Depen-
dency Injection). Auch die Registratur, die in unserem Prototyp eingesetzt wird, soll dazu
zählen, wobei ich diese Art der Komponentenkombination so einschätze, dass die Eigen-
scha E2 dadurch nur schwach vorhanden ist, da zwar die Registratur vom Komponenten-
Framework bereitgestellt wird, aber die Komponenten durch das An- und Abmelden sowie
das Abrufen von Objekten in ihrem Programmcode selbst bei der Verschaltung der Kompo-
nenten intensiv mithelfen müssen. Durch dieses Kopplungsprinzip soll es möglich sein,
dass Komponenten anders kombiniert werden können, ohne dass dazu etwas an den Kom-
ponenten verä ndert wird. Insbesondere soll man Komponenten in einfacher Weise hinzu-
fügen, entfernen und austauschen können. Besonders fl exibel ist ein Komponentensystem,
wenn dies im laufenden Betrieb möglich ist.
E3: Das Komponenten-Framework realisiert einen Lebenszyklus für seine
Komponenten und stellt weitere Dienste für sie bereit.
In der Regel werden die Objekte, zumindest die „Hauptobjekte“ einer Komponente, nicht im
Programmcode der Komponente erzeugt, sondern durch das Komponenten-Framework.
Weiterhin ru das Framework beim Eintritt weiterer Ereignisse Methoden auf den Objekten
der Komponenten auf. Dabei handelt es sich häufi g um Initialisierungsmethoden, wobei
sich die Frage stellt, warum ein Objekt einer Komponente die Initialisierung nicht in seinem
Konstruktor durchführen sollte, sondern in einer separaten Initialisierungsmethode. Der
Grund ist darin zu sehen, dass das Framework nach dem Erzeugen eines Objekts eventuell
