© Excellent backgrounds/Shutterstock.com
Java Magazin
Design Patterns Teil 3: Dynamic Proxy

Der LEGO-Kasten für Softwareentwicklung


Bis jetzt haben wir die Proxy-Klassen per Hand geschrieben und das ist sinnvoll, wenn jeder Proxy-Typ in Struktur und Funktion einzigartig ist. Die meisten Proxy-Implementierungen sind sich aber ähnlich. Remote-Proxys müssen alle Parameter parallelschalten und Werte hin und her senden. Java RMIs (Remote Method Invocations) generieren den Glue Code für verteilte Proxys in Form von Stubs und Skeletons.

Die Codegenerierung kann statisch oder dynamisch erfolgen. Statisch ist es weniger komfortabel, da ein zusätzlicher Schritt im Build-Prozess erforderlich ist. Dynamische Codegenerierung erzeugt zur Laufzeit eine neue Proxy-Klasse, die sehr bequem und flexibel ist.

Proxy.newProxyInstanz()

Dynamische Proxies werden mit der statischen Factory-Methode newProxyInstance() mit diesen drei Parametern konstruiert:

  • ClassLoader loader: Hier wird unsere neue Proxy-Klasse hineingeladen. Der ClassLoader muss in der Lage sein, die Interfaces zu sehen, die wir implementieren wollen. Der Class Loader Bootstrap kennt beispielsweise die Java-Schnittstellen (java.lang.Runnable, java.util.Collection usw.), aber nicht die Anwendungsschnittstellen. Unsere Klassen werden mit dem Class Loader System (auch AppClassLoader genannt) geladen.

  • Class<?>[] Interfaces ist ein Array mit allen Schnittstellen, die unser Proxy-Objekt implementieren müssen.

  • InvocationHandler ist eine funktionale Schnittstelle, die aufgerufen wird, wenn eine Methode das Proxy-Objekt aufruft.

Das Factory Design Pattern

Eines der am häufigsten zitierten Muster der GoF ist die sogenannte Factory. Das einzige Problem ist, dass es im Buch kein Factory Pattern gibt. Die GoF beschreiben eine Factory Method, eine abstrakte Methode zur Initialisierung von Objekten, wobei die Konstruktion an Unterklassen delegiert wird. Ein Beispiel ist die Iterator()-Methode, bei der ArrayList ein ArrayList$Itr und LinkedList ein LinkedList$ListItr erzeugt.

Die GoF beschreiben auch eine abstrakte Factory zur Erstellung von Familien verwandter Pro...

Java Magazin
Design Patterns Teil 3: Dynamic Proxy

Der LEGO-Kasten für Softwareentwicklung

Bis jetzt haben wir die Proxy-Klassen per Hand geschrieben und das ist sinnvoll, wenn jeder Proxy-Typ in Struktur und Funktion einzigartig ist. Die meisten Proxy-Implementierungen sind sich aber ähnlich. Remote-Proxys müssen alle Parameter parallelschalten und Werte hin und her senden. Java RMIs (Remote Method Invocations) generieren den Glue Code für verteilte Proxys in Form von Stubs und Skeletons.

Sven Ruppert, Heinz Kabutz


Bis jetzt haben wir die Proxy-Klassen per Hand geschrieben und das ist sinnvoll, wenn jeder Proxy-Typ in Struktur und Funktion einzigartig ist. Die meisten Proxy-Implementierungen sind sich aber ähnlich. Remote-Proxys müssen alle Parameter parallelschalten und Werte hin und her senden. Java RMIs (Remote Method Invocations) generieren den Glue Code für verteilte Proxys in Form von Stubs und Skeletons.

Die Codegenerierung kann statisch oder dynamisch erfolgen. Statisch ist es weniger komfortabel, da ein zusätzlicher Schritt im Build-Prozess erforderlich ist. Dynamische Codegenerierung erzeugt zur Laufzeit eine neue Proxy-Klasse, die sehr bequem und flexibel ist.

Proxy.newProxyInstanz()

Dynamische Proxies werden mit der statischen Factory-Methode newProxyInstance() mit diesen drei Parametern konstruiert:

  • ClassLoader loader: Hier wird unsere neue Proxy-Klasse hineingeladen. Der ClassLoader muss in der Lage sein, die Interfaces zu sehen, die wir implementieren wollen. Der Class Loader Bootstrap kennt beispielsweise die Java-Schnittstellen (java.lang.Runnable, java.util.Collection usw.), aber nicht die Anwendungsschnittstellen. Unsere Klassen werden mit dem Class Loader System (auch AppClassLoader genannt) geladen.

  • Class<?>[] Interfaces ist ein Array mit allen Schnittstellen, die unser Proxy-Objekt implementieren müssen.

  • InvocationHandler ist eine funktionale Schnittstelle, die aufgerufen wird, wenn eine Methode das Proxy-Objekt aufruft.

Das Factory Design Pattern

Eines der am häufigsten zitierten Muster der GoF ist die sogenannte Factory. Das einzige Problem ist, dass es im Buch kein Factory Pattern gibt. Die GoF beschreiben eine Factory Method, eine abstrakte Methode zur Initialisierung von Objekten, wobei die Konstruktion an Unterklassen delegiert wird. Ein Beispiel ist die Iterator()-Methode, bei der ArrayList ein ArrayList$Itr und LinkedList ein LinkedList$ListItr erzeugt.

Die GoF beschreiben auch eine abstrakte Factory zur Erstellung von Familien verwandter Pro...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang