Dependency Injection

Practice, Practice, Practice A young concert violinist got lost on his way to a performance. He stoped an old man on the corner and asked him how to get to Carnige Hall. The old man looked at the violinist and the violin tucked under his arm, and said: “ Practice, son, Practice ! ” Theory-Practice: a positive feedback system

public class Emailer { private SpellChecker spellChecker; public Emailer() { this.spellChecker = new SpellChecker(); } public void send(String text) { .. } } How about testing? public class MockSpellChecker extends SpellChecker { private boolean didCheckSpelling = false; public boolean checkSpelling(String text) { didCheckSpelling = true; return true; } public boolean verifyDidCheckSpelling(){ return didCheckSpelling; } } And what about the Open-Closed Principle?

The Factory Pattern public class EmailerFactory { /* The Factory is explicit about the object it produces...*/ public Emailer newItalianEmailer() { return new Emailer(new ItalianSpellChecker()); } } Emailer service = new EmailerFactory().newItalianEmailer(); @Test public void testEmailer() { MockSpellChecker spellChecker = ... Emailer emailer = new Emailer( spellChecker ); emailer.send("Fatte DI in ufficio!"); assert ...; } Client Factory Service

What about the client? public class EmailerClient { private Emailer emailer = new EmailerFactory().newItalianEmailer(); public void sendEmail() { emailer.send(createMessage()); } } public class EmailerFactory { private static Emailer instance; // did you see the problem here? public Emailer newEmailer() { if (null == instance) return new Emailer(..); return instance; } static void set (Emailer mock) { instance = mock; } } @Test public void testEmailClient() { MockEmailer mock = new MockEmailer(); EmailerFactory.set(mock); new EmailClient().sendEmail(); assert mock.correctlySent(); } @Test public void testEmailClient() { MockEmailer mock = new MockEmailer(); EmailerFactory.set(mock); try { new EmailClient().sendEmail(); assert mock.correctlySent(); } finally { EmailerFactory.set(null); } }

The Service Locator Pattern Is a generalization of the Factory Emailer emailer = (Emailer) new ServiceLocator().get("ItalianEmailer"); Emailer emailer = (Emailer) new ServiceLocator().get(" JapaneseEmailerWithPhoneAndEmail "); (as a Factory) suffers from same problems: testability and shared state Do you remember the ServiceManager anti-pattern?

DI Hollywood Principle Behaviorally focused Modular Separation of concerns, Demeter's law, Decoupling TESTABLE

My main(String... args) is better than yours... public class EmailerClient { private final Emailer emailer; public EmailerClient(Emailer emailer){ this.emailer = emailer; } public void sendEmail() { emailer.send(createMessage()); } ... } public static void main(String... args) throws Exception { // by hand (new ApplicationFactory(args).create()).start(); } public static void main(String... args) throws Exception { // using Guice Injector injector = Guice.createInjector(new ApplicationModule(args)); (injector.getInstance(Application.class)).start(); }

What have changed? Client code (EmailerClient) doesn't invoke the injector (separation of concerns) The root-object is explicit (Application.class) The injector obtains instances within current execution context (scoping)

How to identify a dependency Dependency: Contract Variants public interface SpellChecker { boolean check(String text); } class ItalianSpellChecker implements SpellChecker { public boolean check(String text) {/* check italian */ ...} } class EnglishSpellChecker implements SpellChecker { public boolean check(String text) {/* check english */ ...} } (new Emailer( new EnglishSpellChecker() )).send(“Hello”); (new Emailer( new ItalianSpellChecker() )).send(“Ciao”); KEY: Unique Arbitrary Explicit

String Keys (Spring) Pros Unique Arbitrary Explicit Cons Error-prone No compile-time safe You “can't” use Vim but IntelliJ Idea Must be carefully choosen Examples: <beans ...> <bean id=”spelling.english” class=”it.xpug.milan.service.text. EnglishSpellChecker ”/> <bean id=”spelling.italian” class=”it.xpug.milan.service.text.ItalianSpellChecker”/> </beans>

Identifying by Type Pros Compile-time safe Right direction Cons Not unique Not arbitrary Explicitness? Inflexible Examples: SpellChecker.class identifies EnglishSpellChecker or ItalianSpellChecker Emailer.class identifies itself

Combinatorial Keys (Guice) Key = [contract, variant] Key1: [Emailer.class, “english”] Key2: [Emailer.class, “italian”] Key3: [Emailer.class, “English”] Or better: Key1: [Emailer.class, English.class] Key2: [Emailer.class, Italian.class] @Retention( RUNTIME ) @Target( { PARAMETER } ) public @interface English { ... } public class Emailer{ private final SpellChecker spellChecker; @Inject public SpellCheckerClient( @English SpellChecker spellChecker) { this. spellChecker = spellChecker; } } public class SpellingModule extends AbstractModule { @Override protected void configure() { bind(SpellChecker.class) . annotatedWith(English.class) . to(EnglishSpellChecker.class); }

Injection Idioms Setter injection public class Emailer { private SpellChecker spellChecker; public void setSpellChecker (SpellChecker spellChecker) { this. spellChecker = spellChecker; } } <beans ...xmlns:p="http://www.springframework.org/schema/p"...> <bean id="spelling.english" class="package.EnglishSpellChecker"/> <bean id=”emailer” class =”package.Emailer” p:spellChecker="spelling.english"/> </beans> Interface Injection (Deprecated) Method Decoration (via AOP)

Constructor Injection public class Emailer { private final SpellChecker spellChecker; // potentially immutable public Emailer(SpellChecker spellChecker){ this.spellChecker = spellChecker; // freezing the object graph } } <beans ...> <bean id=”emailer” class =”package.Emailer”> <constructor-arg> <bean class="package.EnglishSpellChecker"/> </constructor-arg> </bean> </beans>

Constructor vs Setter Injection Constructor Clear contract Immutability support or temporal encapsulation Ready for use/ Object validity No need for noisy setters Setter Esplicitness (type indipendent) Doesn't suffers from the pyramid/telescoping problem Doesn't suffers from the circular dependency and some in-construction problems

GOF's Creational Patterns Abstract Factory Factory Method Builder Prototype Singleton

The Reinjection Problem When a long-lived dependent needs a short-lived dependencies public class Granny { private Apple apple; public Granny(Apple apple) { this.apple = apple; } public void eat() { apple.consume(); apple.consume(); } } /** Provides specific object and scoped intances of those objects. */ public interface Provider<T> { T get(); } public class AppleProvider implements Provider<Apple>{ public Apple get(){ return new Apple(); } } public class Granny { private Provider<Apple> appleProvider; public Granny(Provider<Apple> ap) { this.appleProvider = ap; } public void eat() { appleProvider.get().consume(); appleProvider.get().consume(); } }

Or using the builder pattern.. public class Granny { private AppleBuilder builder; public Granny(AppleBuilder b) { this.builder = b; } public void eat() { builder.buildRedApple().consume(); builder.buildGreenApple().consume(); } } public class AppleBuilder { public Apple buildRedApple() { return new RedApple(); } public Apple buildGreenApple() { return new GreenApple(); } } and its Jochua's version...

The Contextual Injection Problem public class NewsletterManager { private final List<Recipient> recipients; private final AssistedProvider<Deliverer, Newsletter> deliverer; public NewsletterManager(List<Recipient> rs,AssistedProvider<Deliverer,Newsletter> dp){ this.recipients = rs; this.deliverer = dp; } public void send(Newsletter letter) { for (Recipient recipient : recipients) { Deliverer d = deliverer.get(letter); d.deliverTo(recipient); } } } public interface AssistedProvider<T, C> { T get(C context); } public class DelivererProvider implements AssistedProvider<Deliverer,Newsletter> { public Deliverer get(Newsletter letter) { return new Deliverer(letter); } }

Scope Is a fixed duration of time or method calls in which an object exists A context under which a given key refers to the same instance Mostly used: Singleton and No-Scope Interesting scopes: Transaction, Web, Cache, Thread, Grid, Custom...

Why Scope? Applies the Hollywood Principle to the state of the objects The injector manages the latent state of your objects The injector ensures that the services get new instance of dependencies as needed Implicity separates state by context Reduces the necessity for state-aware application logic (separation of concerns – infrastructure/business logic)

Defining a Custom Scope Guice public interface Scope { <T> Provider<T> scope(Key<T> key, Provider<T> unscoped); } public class TransactionScope implements Scope { private final ThreadLocal<Map<Key<?>, Object>> instances = new ThreadLocal<Map<Key<?>, Object>>(); public <T> Provider<T> scope( final Key<T> key, final Provider<T> unscoped) { return new Provider<T>() { public T get() { Map<Key<?>, Object> map = instances.get(); if (null == map) { throw new OutOfScopeException("no transaction was active"); } if (!map.containsKey(key)) { map.put(key, unscoped.get()) } return (T) map.get(key); } }; } // called by the transaction framework public void beginScope() { instances.set(new HashMap<Key<?>, Object>()); } public void endScope() {instances.remove();}}

Defining a Custom Scope (Cont.) Spring public interface Scope { Object get(String key, ObjectFactory unscopedProvider); Object remove(String key); String getConversationId(); // scope identity, ex. SessionId // lifecycle method void registerDestructionCallback(String key, Runnable destructionCallback); } <beans ...> <bean class="org.springframework.beans.factory.config.CustomScopeConfigurer"> <property name="scopes"> <map> <entry key="transaction"> <bean class="my.custom.TransactionScope"/> </entry> </map> </property> </bean> ... </beans>

public class TransactionScope implements Scope { private final ThreadLocal<Map<String, Object>> instances = new ThreadLocal<Map<String, Object>>(); public Object get(String key, ObjectFactory unscoped) { Map<String, Object> map = instances.get(); //check out of scope if (null == map) throw new IllegalStateException("no transaction is active"); if (!map.containsKey(key)) { map.put(key, unscoped.getObject()); } return map.get(key); } public void beginScope() { instances.set(new HashMap<String, Object>()); } public void endScope() { instances.remove(); } public Object remove(String key) { // check out of scope ... return instances.get().remove(key); } public String getConversationId() { // check out of scope ... return instances.get().toString(); } public void registerDestructionCallback(String key, Runnable destructionCallback) { ... } }

public static final Scope SINGLETON = new Scope() { public <T> Provider<T> scope(Key<T> key, final Provider<T> creator) { return new Provider<T>() { /* * The lazily initialized singleton instance. Once set, this will either have type T or will * be equal to NULL. */ private volatile Object instance; // DCL on a volatile is safe as of Java 5, which we obviously require. @SuppressWarnings("DoubleCheckedLocking") public T get() { if (instance == null) { /* * Use a pretty coarse lock. We don't want to run into deadlocks * when two threads try to load circularly-dependent objects. * Maybe one of these days we will identify independent graphs of * objects and offer to load them in parallel. */ synchronized (InjectorBuilder.class) { if (instance == null) { T nullableInstance = creator.get(); instance = (nullableInstance != null) ? nullableInstance : NULL; } } } Object localInstance = instance; // This is safe because instance has type T or is equal to NULL @SuppressWarnings("unchecked") T returnedInstance = (localInstance != NULL) ? (T) localInstance : null; return returnedInstance; } public String toString() { return String.format("%s[%s]", creator, SINGLETON); } }; } }; Did you see how it helps to the modularity?

Related stuff Lifecycle Postprocessors AOP

Lifecycle in DI Closely related to the scope but of different semantic Related to the nature of the object Is about state transitions / event driven Moslty used: init and destroy Can be constructed over other specific lifecycles (ex. servlet or db connections) PostProcessors – register to a particular lifecycle

AOP in DI Attention: much power means much responsability! Unit Testing somewhat is fading, much more like Integration Test Aop Alliance (Guice, Spring) AspectJ (Spring)

DI + AOP = DDD? Eric Evans - 2008 Although DDD can be done with any paradigm that allows abstraction and expression of model concepts, in practice it has almost always been OOP. So, OOP has been a foundation of the practice of DDD. More recently, DI has become a very widespread technique and, when used well, has helped practitioners of DDD to improve their designs. Most importantly, in my view, DI helps in the "isolation" of the domain. The potential of AOP is just beginning to be realized. It seems that it has potential to declutter the domain layer. This contributes to the clear expression of the model concepts, and perhaps to isolation. But, unlike the first two (OOP and DI), it isn't a tried and true part of a "foundation" yet. These form a foundation of a current best practice architecture that supports DDD .

DI for Java SE JSR 330 (299-Web Beans?) @Inject - Identifies injectable constructors, methods, and fields @Qualifier - Identifies qualifier annotations @Scope - Identifies scope annotations @Named - String-based qualifier @Singleton - Identifies a type that the injector only instantiates once

Some DI Frameworks Java APACHE AVALON SPRING FRAMEWORK PICOCONTAINER AND NANOCONTAINER APACHE HIVEMIND GOOGLE GUICE BUTTERFLY DI DSL Ruby COPLAND

References Dependency Injection - Dhanji R. Prasanna* http://www.manning.com/prasanna/ Misko Hevery* Blog http://misko.hevery.com/ * Many thanks to both of you from the slide's author

Dependency Injection

More Related Content

What's hot (20)

Similar to Dependency Injection (20)

Recently uploaded (20)

Dependency Injection