Java Reference
In-Depth Information
{
System.out.println("exception: " + e.getMessage());
}
}
}
Die Ausgabe des Programms ist exakt dieselbe wie die beim statischen Proxy in Listing 4.2.
Der wesentliche Unterschied besteht darin, dass der Code beim statischen Proxy genau auf
die Schnittstelle Counter mit den Methoden add und sub sowie den Parametern dieser
Methoden zugeschnitten war. Der Code in diesem letzten Beispiel ist allgemeiner: Die
Klasse MyInvocationHandler lässt sich für jede beliebige Schnittstelle verwenden, und bei
der Erzeugung des dynamischen Proxy muss man lediglich eine andere Schnittstelle in
Form eines anderen Class-Objekts angeben. Mit anderen Worten: Wenn die Anwendung
eine andere ist, so muss der statische Proxy aus Listing 4.2 neu programmiert werden,
während genau der Code aus Listing 4.3 für den dynamischen Proxy unverä ndert weiterver-
wendet werden kann.
Ein Beispiel für eine Benutzung dieser Form dynamischer Proxies ist RMI ab Java-Version 5.
Ein RMI-Stub ist ein Proxy, der stellvertretend auf der Client-Seite die Methodenaufrufe
entgegennimmt, die für das ferne RMI-Objekt auf dem Server gedacht sind. Die Funktion
des RMI-Stubs ist dann die Übertragung der Daten wie Methodenname und Parameter auf
den Server über eine Netzverbindung. RMI-Stubs sind dynamisch erzeugte Proxies.
Ein weiteres Beispiel für die Verwendung dynamischer Proxies haben wir im vorigen Kapi-
tel gesehen. Die Methoden getAnnotations, getDeclaredAnnotations und getAnnotation lie-
fern Annotationsobjekte zurück, die die zu einer Annotation gehörenden Schnittstellen
implementieren. Es wurde im Text gesagt, dass dies Objekte irgendwelcher nicht näher
interessierender Klassen seien. Wie Sie jetzt vielleicht schon vermuten: Damit waren dyna-
mische Proxy-Klassen gemeint.
■
4 . 3 Erzeugung dynamischer Proxies
mit CGLIB
Wir kommen nochmals auf Listing 4.1 zurück. Wir verä ndern das Programm nun so, dass
es die Schnittstelle Counter nicht mehr gibt, sondern nur noch die Klasse CounterImpl, die
dann als Parametertyp in der Methode useCounter der Klasse Main verwendet werden
muss. Wie kann für diese Situation ein Proxy realisiert werden? Die Antwort lautet: Die
Proxy-Klasse muss in diesem Fall aus CounterImpl abgeleitet werden, dann kann das Proxy-
Objekt wie das eigentliche Objekt benutzt werden. Man überschreibt in der abgeleiteten
Proyx-Klasse die Methoden der Basisklasse und implementiert darin die Proxy-Funktiona-
lität. Zum Delegieren der Methodenaufrufe benötigte das Proxy-Objekt in den bisherigen
Beispielen eine Referenz auf das Server-Objekt. Dies ist in diesem Fall auch möglich, aber
nicht unbedingt nötig, denn durch die Vererbung bringt die Proxy-Klasse die „eigentlichen“
Methoden mit, die zwar überschrieben, aber über einen Super-Aufruf immer noch zugäng-
lich sind. Mit anderen Worten: Das Proxy-Objekt ist gleichzeitig auch das Server-Objekt.
