Dependency Injection

Constantine Nosovsky

1

Agenda

Program units coupling

Why one should avoid tight coupling

Problems of coupling reduction

Coupling reduction example

Dependency injection (DI): definition, components, injection type

Inversion of control (IoC)

IoC + DI

Dependency: lifecycle, scope, resolution

Reference implementations

Benefits and disadvantages

2 of 30

Program units coupling

Coupling is a measure of the independence of components

3 of 30

Tight (high, strong) Loose (low, weak) None

Module A

Module C

Module B

Module D

Module A

Module C

Module B

Module D

Module A

Module C

Module B

Module D

Program units coupling: types

Content: A modifies B, B is completely dependent on A

(e. g. A overrides implementation of method in B)

Common: A and B share the same common data

(e. g. A and B share the same global variable)

Control: A passes parameters to control the flow of B

Stamp: A and B share the same Value-Object type

Data: Only data are passed between A and B

Message: Defined message types are sent between A and B

None: A and B do not interact in any way

4 of 30

Why one should avoid tight coupling

A change in one module forces

a ripple effect of changes

in other modules

5 of 30

A particular module is harder

to reuse and test,

because dependent modules

must be included

Warning

Do NOT try to reduce coupling between every pair of units

just for the sake of loyalty, if it doesn’t feel right

Level of coupling is a matter of design, it is neither good or bad

For example:

• Module A doesn’t make any sense without module B

• A and B work as a whole atomic unit

(e.g. pipeline processing)

• The application is made to work with an exact

third-party Service, API or Hardware

6 of 30

Coupling reduction

7 of 30

Problems of coupling reduction

Components independence: modules make no assumptions

about what other systems do, but rely on their contracts

Abstraction: use interface to define a type

and focus on what is important about the component

Instantiation: concrete implementation of the interface

has to be instantiated (creational patterns like Abstract Factory)

Components linking: provide a wiring layer

between components A and B (Service Locator)

8 of 30

Example: tight coupling

public class A {

B b = new B();

C c = new C();

public void doA() {

b.doB();

c.doC();

}

}

9 of 30

Example: abstraction (use interfaces)

public class A {

IB b = new B();

IC c = new C();

public void doA() {

b.doB();

c.doC();

}

}

10 of 30

Example: instantiation (creational

patterns)

public class A {

IB b = FactoryB.createIB();

IC c = FactoryC.createIC();

public void doA() {

b.doB();

c.doC();

}

}

11 of 30

Example: components linking

public class A {

IB b; IC c;

public A(IB b, IC c) {

this.b = b;

this.c = c;

}

public void doA() {

b.doB(); c.doC();

}

}

12 of 30

Example: components linking

13 of 30

public class Starter {

A a; IB b; IC c;

public void startUp() {

b = FactoryB.createIB();

c = FactoryC.createIC();

a = new A(b, c);

}

public A getA() {

return a;

}

}

Example: loose coupling

14 of 30

Dependency injection (DI)

15 of 30

So we noticed that decoupled modules

need to be linked for the interaction

DI: definition

Dependency Injection (DI) is a design pattern

aimed to eliminate the hard-coded dependencies

between program modules and make it possible

to change them at compile-time and/or run-time

16 of 30

DI: components

Dependency: a module that other modules depend on

Consumer (Client): a dependent module

Injector (Container): a component that retrieves/creates

dependencies and wires them to the consumers

Resolver: a component that chooses a concrete implementation

for the abstract type requested

17 of 30

DI: illustration

18 of 30

DI: injection types

Constructor: dependency is wired during the consumer is being

created

Setter: setter method is used to set/change the dependency

Interface: dependency provides an interface that must be

implemented by any dependent client

19 of 30

Inversion of control (IoC)

“Don’t call us, we’ll call you”

Methods defined by the user to tailor the framework will often be

called from within the framework itself

Framework plays the role of main application and user code

defines action to perform in response to application activity

20 of 30

IoC + DI

21 of 30

IoC framework

Application

DI Container

ModulesApplication

ConfigurationLocalized texts,

etc.Configuration

Metadata

IoC + DI: configuration metadata

External: XML or other external metadata format<bean class="com.example.MyComponent"/>

Annotation-based: byte-code level metadata description

@Componentpublic class MyComponent { … }

Code-based: custom code that declares dependencies

@Configurationpublic class AppConfig {

@Bean public MyComponent myComponent () {return new MyComponent();

}

}

22 of 30

Dependency: lifecycle

Creation: dependencies may be created calling the default

constructor (default) or factory method

Callbacks: container provides a set of callbacks called on events:

• Dependency initialization (pre and post)

• Dependency destruction (pre and post)

• Container startup

• Container shutdown

• etc.

23 of 30

Dependency: scopes

Singleton (container): a single instance for the whole container

Prototype: a single definition for any amount of instances

Thread: a single instance per thread (thread scope singleton)

Custom: define your own scope

Web aware containers may provide:

Request

Session

24 of 30

Dependency: resolution

Explicit reference wiring configuration

Autowiring

• Type: the dependency is resolved based on class type

• Name: based on unique component name

• Collections of types

25 of 30

Example: using DI

@Component

public class A {

IB b; IC c;

@Autowired

public A(IB b, IC c) {

this.b = b;

this.c = c;

}

}

26 of 30

Reference implementations

Java

• J2EE 6+ compatible containers (Glassfish, etc.)

• Spring – a part of the large versatile framework

• Google Guice – lightweight, works for android

.NET

• Spring.NET

27 of 30

Benefits

More readable code

More testable code

More reusable code

28 of 30

Disadvantages

Runtime linking cause runtime errors instead of compiletime

Longer application startup

Dependency hell:

• Circular dependencies

• Conflicting dependencies

• Long chains of dependencies

• A lot of dependencies for a simple functionality

29 of 30

Thanks for your attention

?

30 of 30