Wie schon in dem vorherigen Artikel mit JBoss Weld geht es auch in diesem Blog nicht darum, was Dependency Injection ist. Hier geht es um die Lösung der Anforderungen aus dem einleitenden Blog dieses Mal mit Google Guice.
Guice ist im Gegensatz zu Weld nicht JSR-299 konform. Es verwendet eigene Annotations wie z.B. für @Inject und Guice kommt ohne XML-Konfigurationsdatei aus.
Die Implementierung des Generator-Interfaces sowie der Standard- und Kundenanforderung entspricht denen aus der Weld-Umsetzung. Die Verknüpfung der konkreten Implementierung eines Interfaces mit dem Injection-Point erfolgt mittels Modulen. Das Modul für die Standardimplementierung sieht in diesem Beispiel so aus:
/** * @author 7droids.de (FA)<br> * Configuration file for the default implementation */ public class DefaultModule implements Module { /* * (non-Javadoc) * * @see com.google.inject.Module#configure(com.google.inject.Binder) */ @Override public void configure(Binder binder) { binder.bind(IdGenerator.class).to(DefaultIdGenerator.class); } }
Hier wird dem Interface IdGenerator die konkrete Implementierung DefaultIdgenerator zugeordnet. Entsprechend wird im Kundenmodul dem Interface die Klasse CustomIdGenerator zugewiesen.
/** * @author 7droids.de (FA)<br> * Configuration file for custom implementation * */ public class CustomModule implements Module { /* * (non-Javadoc) * * @see com.google.inject.Module#configure(com.google.inject.Binder) */ @Override public void configure(Binder binder) { binder.bind(IdGenerator.class).to(CustomIdGenerator.class); } }
Auch in der Instanziierung einer Klasse mit Injection-Points sieht ein wenig anders aus als bei Weld.
NomintFilter filter = Guice.createInjector(new DefaultModule()) .getInstance(NomintFilter.class);
Bzw.
NomintFilter filter = Guice.createInjector(new CustomModule()) .getInstance(NomintFilter.class);
Der Injector (Guice.createInjector(Module)) sollte wie bei Weld auch nur einmal je Applikation mit dem entsprechenden Modul initialisiert werden.
Zusammenfassung
In der nachfolgenden Tabelle sind die Eigenheiten, Vor- und Nachteile der einzelnen Umsetzungen noch einmal aufgelistet.
Hookup | Weld | Guice | |
---|---|---|---|
Klassenname bleibt erhalten | Ja | Ja | Ja |
Instanziierung via Reflection möglich | Ja | Ja(?) | Ja(?) |
Einfach zu testen | Bedingt | Ja | Ja |
Kapselung der Änderung | Nein | Ja | Ja |
JSR-299 konform | Nein | Ja | Nein |
Konfiguration über XML | Nein | Ja | Nein |
Die Klassen inklusive Unittests sind als Maven-Projekt im Git-Repository unter git://github.com/7droids/ProductBreakPoint.git verfügbar.