Java Reference
In-Depth Information
Die Schwierigkeit bei der Defi nition von Java-Komponenten liegt darin, dass die Defi nition
allgemein genug sein soll, damit alle diejenigen Systeme, die in diesem Buch vorgestellt
werden und gemeinhin als Java-Komponentensysteme gelten, unter die Defi nition fallen.
Wenn man ein Komponentensystem (beispielsweise das prototypische Framework aus dem
vorigen Kapitel) als Vorlage für eine enge Defi nition heranziehen würde, dann würden
andere Frameworks eventuell nicht mehr als Komponentensysteme zählen, obwohl die All-
gemeinheit das anders sieht. Die Defi nition darf also einerseits nicht zu eng sein. Sie sollte
aber andererseits auch nicht zu weit gefasst sein, damit nicht jedes beliebige So ware-Sys-
teme als Komponentensystem gelten kann.
Übrigens soll ganz bewusst nicht gefordert werden, dass sich alle Komponenten eines Kom-
ponentensystems in einem Prozess befi nden müssen. In unserem Prototyp und auch in
vielen „real existierenden“ Komponentensystemen ist das zwar so, aber es gibt auch Kom-
ponentensysteme, die auf mehrere Prozesse und sogar auf mehrere Rechner verteilt sind.
Genauso wenig soll gefordert werden, wie das manchmal zu lesen ist, dass eine Kompo-
nente mehr als eine Klasse umfassen muss. Das mag zwar in der Praxis in den meisten
Fällen so sein, aber es sollte möglich sein, einfache Beispiele für Komponenten anzugeben,
die auch nur aus einer Klasse bestehen und dennoch das Prinzip einer Komponente für ein
bestimmtes Komponentenmodell illustrieren.
■
7.3 Eigenscha en von Java-Komponenten
Die Problematik der obigen Defi nitionen hängt u. a. damit zusammen, dass die Defi nition
von So ware-Komponenten sehr allgemeingültig sein soll. Die Aufgabe ist in unserem Fall
allerdings etwas einfacher, da sich dieses Buch — wie der Titel angibt — auf Java-Komponen-
ten beschränkt. Sie werden im folgenden Abschnitt auch keine klare Defi nition von Java-
Komponenten fi nden, aber einige Eigenscha en, die Java-Komponenten typischerweise
besitzen sollen oder können. Dabei wird nicht verlangt, dass eine Java-Komponente bzw. ein
Java-Komponenten-Framework alle diese Eigenscha en besitzen muss. Auß erdem besitzen
einige Eigenscha en mehrere Varianten und sind somit in gewisser Weise auch wieder
vage. Der Nutzen in der Angabe dieser Eigenscha en besteht allerdings darin, dass die
Leserinnen und Leser in die Lage versetzt werden selbst einzuschätzen, ob eine gewisse
Java-Plattform mehr oder wenig stark als komponentenbasiert bzw. komponentenorientiert
charakterisiert werden kann.
Komponentensysteme und Komponenten können oder sollen im Rahmen dieses Buches die
folgenden Eigenscha en E1 bis E4 aufweisen:
E1: Komponenten sind klar identifi zierbare Einheiten, die konform sind zu
einem vorgegebenen Komponentenmodell.
Für ein Komponentensystem ist klar defi niert, was eine Komponente ist. Im einfachsten Fall
kann eine Komponente ein Objekt bzw. eine Klasse sein. Häufi ger bestehen Komponenten
wie in unserem Prototyp aus Programmcode in Form mehrerer Class-Dateien, aus Konfi gu-
rationsinformationen in Form einer XML- oder Manifest-Datei sowie eventuell aus weiteren
