Java Reference
In-Depth Information
noch bestimmte Manipulationen an dem erzeugten Objekt vornimmt. Typisch wäre z. B. die
Zuweisung von Referenzen auf andere vom Framework erzeugte oder bereitgestellte Objekte
an die Attribute des Objekts z. B. durch Dependency Injection. Erst danach soll sich das
Objekt einer Komponente dann anwendungsabhängig initialisieren. Aus diesem Grund
wird die Initialisierung häufi g in separaten Initialisierungsmethoden durchgeführt, die
vom Framework aufgerufen werden. Symmetrisch dazu ru das Framework auch Methoden
auf, wenn eine Komponente deinstalliert wird. Dies haben wir in Form der Start- und Stop-
Methoden im Prototypsystem schon gesehen. Dazwischen können weitere Aufrufe vom
Komponenten-Framework erfolgen, z. B. kurz bevor ein Objekt aus Performance-Gründen
vom Komponenten-Framework ausgelagert und passiv gesetzt wird sowie kurz nachdem
ein Objekt wieder aktiv wurde. Welche Methoden bei welchem Ereignis aufgerufen werden,
kann durch die Methoden einer Schnittstelle oder einer Basisklasse festgelegt sein, die von
der Komponentenklasse implementiert bzw. überschrieben werden. Eine andere Möglich-
keit ist das Annotieren von Methoden. In der Regel können bestimmte Methoden nur aufge-
rufen werden, wenn sich ein Objekt in einem bestimmten Zustand befi ndet. Die Zustands-
wechsel werden in der Regel durch ein Zustandsdiagramm beschrieben. Darin ist festgelegt,
welche Methoden in welchem Zustand vom Framework aufgerufen werden (z. B. kann die
Methode, dass ein Objekt wieder aktiv geworden ist, nicht aufgerufen werden, wenn das
Objekt schon aktiv ist). Man bezeichnet die möglichen Zustandsänderungen, die durch das
Zustandsdiagramm dargestellt werden, auch als den Lebenszyklus eines Objekts. Die
Methodenaufrufe im Rahmen des Lebenszyklus werden vom Framework auf die Objekte der
Komponenten durchgeführt (in Bild 6.1 sind das Aufrufe von unten nach oben; sie werden
auch als Upcalls oder Callbacks bezeichnet). Umgekehrt ist es auch möglich, dass die Kom-
ponenten Dienste, die vom Framework zur Verfügung gestellt werden, nutzen. Zu diesen
Diensten kann beispielsweise ein von allen Komponenten gemeinsam nutzbarer Speicher-
bereich gehören.
E4: Eine Komponente defi niert explizit, was sie für andere Komponenten
bereitstellt und was sie von anderen Komponenten benötigt.
Eine Komponente kann vom Vorhandensein anderer Komponenten abhängig sein (d. h. eine
Komponente nutzt andere Komponenten) und kann eine Plattform für andere Komponenten
bieten (d. h. eine Komponente wird von anderen Komponenten genutzt). Wenn jede Kompo-
nente explizit angibt, was sie für andere Komponenten bereitstellt und was sie von anderen
Komponenten erwartet, dann kann bei der Kombination von Komponenten bereits über-
prü werden, ob die Kombination erfolgreich durchgeführt werden kann oder nicht. Die
Angaben können in Form von Komponenten, Packages, Klassen oder eindeutigen Bezeich-
nern erfolgen. Im prototypischen Komponenten-Framework wurde die Abhängigkeit durch
die Angabe der Komponente ausgedrückt. Die Eigenscha E4 steht in einem gewissen Span-
nungsverhältnis zur Eigenscha E2. Je spezifi scher eine Abhängigkeit ausgedrückt wird,
umso weniger frei sind Komponenten kombinierbar.
