© Excellent backgrounds/Shutterstock.com
Java Magazin
Teil 4: Typesafe DynamicObjectAdapter

Nächster Schritt: typsicher


In den letzten Teilen dieser Artikelserie hatten wir uns mit dem DynamicObjectAdapter beschäftigt. Wir haben ihn mit einigen Modifikationen und Ergänzungen so aufbereitet, dass wir mittels eines Builders nur noch gültige Adapter verwenden konnten und die Anwendung sehr viel einfacher war. Leider war in der letzten Lösung doch recht viel manuelle Tätigkeit notwendig. Das wird sich nun ändern.

Wir haben uns das letzte Mal mit dem DynamicObjectAdapter auseinandergesetzt, der es uns ermöglicht, einzelne Methoden zu adaptieren, ohne den Adapter in der Vererbung haben zu müssen. Um das sicherer zu gestalten, haben wir für die jeweiligen Methoden Functional Interfaces erzeugt und sie als Parameter in einem Builder in den jeweiligen with-Methoden verwendet. Damit haben wir sowohl den Builder als auch den DynamicObjectAdapter in Kombination gebracht und für die Verwendung eine robuste und einfache Handhabung ermöglicht. Aber es ist nicht automatisch gewährleistet, dass Modifikationen direkt bei einem Übersetzungsprozess erkannt werden können. Jedoch sind alle Informationen vorhanden, um diesem Problem zu begegnen und dabei auch noch viel manuelle Arbeit zu sparen.

Artikelserie

Teil 1: Das Builder-Pattern im Einsatz

Teil 2: Das Proxy-Pattern im Einsatz

Teil 3: Das DynamicObjectAdapter-Pattern im Einsatz

Teil 4: Typesafe DynamicObjectAdapter

Das Vorgehen ist immer dasselbe und sehr geradlinig. Von dem Zielinterface werden alle Methodensignaturen genommen und dazu jeweils Functional Interfaces erzeugt. Gehen wir in unserem Beispiel von einem Interface mit dem Namen Service aus:

 public interface Service { String doWork_A(String txt); String doWork_B(String txt); }

In diesem Interface sind nun zwei Methoden definiert. Gehen wir nun davon aus, dass wir zu diesem Interface zwei weitere Interfaces definieren. Diese enthalten jeweils eine der Methodendefinitionen:

 public interface ServiceDoWork_A { String doWork_A(String txt); } public interface ServiceDoWork_B { String doWork_B(String txt); }

Um eindeutige Namen für die Interfaces zu bekommen, sollte man sich ein Namensschema überlegen. Hier habe ich einfach den Namen des Originalinterface um den Methodennamen erweitert.

Bisher haben wir diese Functional Interfaces manuell erzeugt. Doch bei der Betrachtung des Quelltexts fällt einem recht schnell auf, dass es sich um Muster handelt, die sich bestens eigenen, um mit einem Generator erzeugt zu werden. Die Antwort liegt in der Verwendung des Annotation-Processor-Plug-ins...

Java Magazin
Teil 4: Typesafe DynamicObjectAdapter

Nächster Schritt: typsicher

In den letzten Teilen dieser Artikelserie hatten wir uns mit dem DynamicObjectAdapter beschäftigt. Wir haben ihn mit einigen Modifikationen und Ergänzungen so aufbereitet, dass wir mittels eines Builders nur noch gültige Adapter verwenden konnten und die Anwendung sehr viel einfacher war. Leider war in der letzten Lösung doch recht viel manuelle Tätigkeit notwendig. Das wird sich nun ändern.

Sven Ruppert


In den letzten Teilen dieser Artikelserie hatten wir uns mit dem DynamicObjectAdapter beschäftigt. Wir haben ihn mit einigen Modifikationen und Ergänzungen so aufbereitet, dass wir mittels eines Builders nur noch gültige Adapter verwenden konnten und die Anwendung sehr viel einfacher war. Leider war in der letzten Lösung doch recht viel manuelle Tätigkeit notwendig. Das wird sich nun ändern.

Wir haben uns das letzte Mal mit dem DynamicObjectAdapter auseinandergesetzt, der es uns ermöglicht, einzelne Methoden zu adaptieren, ohne den Adapter in der Vererbung haben zu müssen. Um das sicherer zu gestalten, haben wir für die jeweiligen Methoden Functional Interfaces erzeugt und sie als Parameter in einem Builder in den jeweiligen with-Methoden verwendet. Damit haben wir sowohl den Builder als auch den DynamicObjectAdapter in Kombination gebracht und für die Verwendung eine robuste und einfache Handhabung ermöglicht. Aber es ist nicht automatisch gewährleistet, dass Modifikationen direkt bei einem Übersetzungsprozess erkannt werden können. Jedoch sind alle Informationen vorhanden, um diesem Problem zu begegnen und dabei auch noch viel manuelle Arbeit zu sparen.

Artikelserie

Teil 1: Das Builder-Pattern im Einsatz

Teil 2: Das Proxy-Pattern im Einsatz

Teil 3: Das DynamicObjectAdapter-Pattern im Einsatz

Teil 4: Typesafe DynamicObjectAdapter

Das Vorgehen ist immer dasselbe und sehr geradlinig. Von dem Zielinterface werden alle Methodensignaturen genommen und dazu jeweils Functional Interfaces erzeugt. Gehen wir in unserem Beispiel von einem Interface mit dem Namen Service aus:

 public interface Service { String doWork_A(String txt); String doWork_B(String txt); }

In diesem Interface sind nun zwei Methoden definiert. Gehen wir nun davon aus, dass wir zu diesem Interface zwei weitere Interfaces definieren. Diese enthalten jeweils eine der Methodendefinitionen:

 public interface ServiceDoWork_A { String doWork_A(String txt); } public interface ServiceDoWork_B { String doWork_B(String txt); }

Um eindeutige Namen für die Interfaces zu bekommen, sollte man sich ein Namensschema überlegen. Hier habe ich einfach den Namen des Originalinterface um den Methodennamen erweitert.

Bisher haben wir diese Functional Interfaces manuell erzeugt. Doch bei der Betrachtung des Quelltexts fällt einem recht schnell auf, dass es sich um Muster handelt, die sich bestens eigenen, um mit einem Generator erzeugt zu werden. Die Antwort liegt in der Verwendung des Annotation-Processor-Plug-ins...

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