© Excellent backgrounds/Shutterstock.com
Java Magazin
Design Patterns Teil 1: Dynamic Proxys

LEGO-Kasten für Softwareentwickler

Wir schreiben das Jahr 2000. Unsere Branche hat den Millennium-Bug überlebt. Ein Smartphone kann auch die Uhrzeit anzeigen. Java ist eine Sprache ohne Generics, Lambdas oder Typinferenz. Die Bereitstellung von EAR-Dateien dauert ewig. EAR-Dateien? Genau, das Spring Framework ist nämlich noch Jahre von der Markteinführung entfernt. Richtige Programmierer verwenden RMI und CORBA.

Sven Ruppert, Heinz Kabutz


Tools generieren eine gewaltige Masse von Infrastrukturcode. Ein Beispiel dafür ist der Compiler rmic, der Stubs und Skeletons zur Unterstützung von Remote-Proxys für RMI (Remote Method Invocation) in Java erzeugt. Erstaunlicherweise besteht rmic in modernen Java-Distributionen im Verzeichnis JDK/bin weiter.

Im Mai 2000 hat Sun Microsystems Java 1.3 und damit Dynamic Proxys herausgebracht.

Statische Factoring-Methoden erzeugen Interfaceinstanzen und leiten alle Methodenaufrufe über einen einzigen InvocationHandler weiter. Dieser wird vom RMI verwendet, um Stubs und Skeletons im Speicher anzulegen.

Großer Fortschritt

Dynamic Proxys erleichtern die Wartung von Code. Anstelle einer großen Anzahl von manuell erstellten Klassen schreiben wir einen einzigen Dynamic Proxy, getreu dem DRY-Prinzip (Don’t Repeat Yourself).

Ein Beispiel: Ein Unternehmen mit mehreren Hundert Business Entitys hatte ein Zaubertool geschrieben, um ihre proprietäre Sprache in Java zu übersetzen. Das Tool konvertierte jede Entity in mehrere Java-Klassen. Nach dieser ersten Generierung mussten die Programmierer den Code jedoch von Hand warten, was sehr aufwendig und fehleranfällig war.

Der generierte Code enthielt Factories, die ein wenig an Home Interfaces in EJB erinnerten. Das waren allein schon rund 600 000 Codeanweisungen. Ein einziger Dynamic Proxy ersetzte all das. Weniger Code, einfachere Wartung.

Dynamic Proxys werden von vielen der von uns täglich verwendeten Frameworks unter der Haube verwendet. So etwa im Spring Framework, WildFly, der NetBeans-Plattform, Apache Tomcat und dem OpenJDK, um nur einige zu nennen.

Aber Moment ...

Dynamic Proxys sind nicht immer das beste Tool. Obwohl sehr praktisch, büßen Methodenaufrufe an einen Dynamic Proxy im Vergleich zu direkten Methodenaufrufen ein bisschen an Leistung ein. In dieser Artikelserie erfahren wir, wie wir diese Leistungseinbußen bei Verwendung Dynamic Proxys minimieren können.

Lernziel

Es gibt Fälle, in denen Dynamic Proxys die ideale Lösung für ein bestimmtes Problem sind. Sie werden Dynamic Proxys ganz genau kennenlernen und sie in einer Reihe von Szenarien sehen. Dadurch werden Sie einschätzen lernen, wann Dynamic Proxys sinnvoll sind und wann nicht.

Außerdem werden Sie ihre Stärken und Schwächen erkennen können, was die Fehlerbehebung in Systemen mit Dynamic Proxys erleichtert.

tl;dr?

Das Lesen und Verstehen einer Artikelserie wie dieser dauert Stunden. Die JavaSpecialists haben einen Kurs zum Selbststudium [1] für diejenigen entwickelt...

Java Magazin
Design Patterns Teil 1: Dynamic Proxys

LEGO-Kasten für Softwareentwickler

Wir schreiben das Jahr 2000. Unsere Branche hat den Millennium-Bug überlebt. Ein Smartphone kann auch die Uhrzeit anzeigen. Java ist eine Sprache ohne Generics, Lambdas oder Typinferenz. Die Bereitstellung von EAR-Dateien dauert ewig. EAR-Dateien? Genau, das Spring Framework ist nämlich noch Jahre von der Markteinführung entfernt. Richtige Programmierer verwenden RMI und CORBA.

Sven Ruppert, Heinz Kabutz


Tools generieren eine gewaltige Masse von Infrastrukturcode. Ein Beispiel dafür ist der Compiler rmic, der Stubs und Skeletons zur Unterstützung von Remote-Proxys für RMI (Remote Method Invocation) in Java erzeugt. Erstaunlicherweise besteht rmic in modernen Java-Distributionen im Verzeichnis JDK/bin weiter.

Im Mai 2000 hat Sun Microsystems Java 1.3 und damit Dynamic Proxys herausgebracht.

Statische Factoring-Methoden erzeugen Interfaceinstanzen und leiten alle Methodenaufrufe über einen einzigen InvocationHandler weiter. Dieser wird vom RMI verwendet, um Stubs und Skeletons im Speicher anzulegen.

Großer Fortschritt

Dynamic Proxys erleichtern die Wartung von Code. Anstelle einer großen Anzahl von manuell erstellten Klassen schreiben wir einen einzigen Dynamic Proxy, getreu dem DRY-Prinzip (Don’t Repeat Yourself).

Ein Beispiel: Ein Unternehmen mit mehreren Hundert Business Entitys hatte ein Zaubertool geschrieben, um ihre proprietäre Sprache in Java zu übersetzen. Das Tool konvertierte jede Entity in mehrere Java-Klassen. Nach dieser ersten Generierung mussten die Programmierer den Code jedoch von Hand warten, was sehr aufwendig und fehleranfällig war.

Der generierte Code enthielt Factories, die ein wenig an Home Interfaces in EJB erinnerten. Das waren allein schon rund 600 000 Codeanweisungen. Ein einziger Dynamic Proxy ersetzte all das. Weniger Code, einfachere Wartung.

Dynamic Proxys werden von vielen der von uns täglich verwendeten Frameworks unter der Haube verwendet. So etwa im Spring Framework, WildFly, der NetBeans-Plattform, Apache Tomcat und dem OpenJDK, um nur einige zu nennen.

Aber Moment ...

Dynamic Proxys sind nicht immer das beste Tool. Obwohl sehr praktisch, büßen Methodenaufrufe an einen Dynamic Proxy im Vergleich zu direkten Methodenaufrufen ein bisschen an Leistung ein. In dieser Artikelserie erfahren wir, wie wir diese Leistungseinbußen bei Verwendung Dynamic Proxys minimieren können.

Lernziel

Es gibt Fälle, in denen Dynamic Proxys die ideale Lösung für ein bestimmtes Problem sind. Sie werden Dynamic Proxys ganz genau kennenlernen und sie in einer Reihe von Szenarien sehen. Dadurch werden Sie einschätzen lernen, wann Dynamic Proxys sinnvoll sind und wann nicht.

Außerdem werden Sie ihre Stärken und Schwächen erkennen können, was die Fehlerbehebung in Systemen mit Dynamic Proxys erleichtert.

tl;dr?

Das Lesen und Verstehen einer Artikelserie wie dieser dauert Stunden. Die JavaSpecialists haben einen Kurs zum Selbststudium [1] für diejenigen entwickelt...

Neugierig geworden?


    
Loading...

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