Hot Topic: Dependency Injection - Let's Talk about it

Hot Topic: Dependency Injection
Let's Talk about it!
Yannick Baron
https://www.thinktecture.com/yannick-baron

View Slide

"list dependencies in the constructor and magically have them available"
• design pattern based on the Inversion of Control principle
• different styles of injection (Constructor, Setter, ...)
Dependency Injection (DI)

View Slide

• principle in software design
• take control from individual class (or function)
• give control to application
• essentially: making things pluggable
→ Dependency Injection is a way to achieve Inversion of Control
Inversion of Control (IoC)

View Slide

• transparency: easily determine dependencies of a class
• reuse: pluggable logic / change behaviour "from the outside"
• testing: a whole lot easier
Why Dependency Injection?

View Slide

// Consumers 
new Consumer1(); 
new Consumer2();
what do consumers depend on?

View Slide

// Consumers 
Consumer1() { 
new FileLogger(); 
new Communicator(); 
} 
Consumer2() { 
new AuthHandler(); 
}
consumers should not have to know
about how to instantiate Service
classes
no way to replace an implementation
(FileLogger vs ConsoleLogger)

View Slide

// Services 
FileLogger() { new FileWriter(); } 
HttpClient() { } 
AuthHandler() { new HttpClient(); } 
Communicator() { new HttpClient(); }
// Consumers 
Consumer1() { 
} 
Consumer1() { 
new AuthHandler(); 
}
consumers should not have to know
about how to instantiate Service
classes
no way to replace an implementation
(FileLogger vs ConsoleLogger)
what if we want the same instance of
the HttpClient in multiple classes?
(singleton? yikes.)
duplication of construction logic

View Slide

// Services 
const logs = new FileLogger(); 
const http = new HttpClient(); 
const comm = new Communicator(http); 
const auth = new AuthHandler(http); 
 
// Consumers 
new Consumer1(logs, comm); 
new Consumer2(logs, comm, auth);
easy to identify dependencies
consumer does not know about the
intricacies of instantiating a
dependency
easily replace a dependency
(interfaces!)
same instance goes to different
consumers
creation logic once where we
bootstrap the app

View Slide

• collection of creation logic and instances
• keeps all creation logic in a single place
• keeps creation logic out of our classes
• can create an instance when it is needed
Dependency Injection Containers

View Slide

• small project with very few classes → no DI Container needed
• huge projects with multiple entry points do not need instances of all classes 
e.g. API request to single controller (simple dispatcher) 
route deﬁnition → instantiates controller → needs dependencies → responds
• after setup, simple usage: 
 
const consumer1 = container.get(Consumer1); 
• dependencies created for us but still replaceable
Dependency Injection Containers

View Slide

Let's build it!
STOP. DEMOTIME.

View Slide

// Service Locator 
new Consumer1(container) 
new Consumer2(container)
// Dependency Injection 
new Consumer1( 
container->get(FileLogger), 
container->get(Communicator), 
) 
new Consumer2( 
container->get(FileLogger), 
container->get(Communicator), 
container->get(AuthHandler), 
) 
Service Locator
hides dependencies
complicates creation logic
couples consumers to container
couples the whole app

View Slide

Automagic DI
... or how it's done in Typescript

View Slide

Quick Interlude: Decorators

View Slide

function getUserRoles(user): Role[] { 
if (!userExists(user) || !isLoggedIn(user)) { 
throw Error('The user does not exist or is not logged in'); 
} 
... 
}
function getUserPermissions(user): Permission[] { 
} 
... 
}

View Slide

function getUserRoles(user: User): Role[] { 
} 
... 
}
function getUserPermissions(user: User): Permission[] { 
} 
... 
}

View Slide

• design pattern
• function or class that wraps another function or class
• can be used to reduce code duplication
• can be used to extend functionality of the wrapped object / function
Decorators

View Slide

function LoggedInUser(target: any) { 
const user = getUserParam(target); 
} 
return target; 
} 
 
@LoggedInUser // Syntactic Sugar 
function getUserRoles(user: User): Role[] { 
... 
} 
 
@LoggedInUser 
function getUserPermissions(user: User): Permission[] { 
... 
} 

View Slide

• upcoming spec in JavaScript 
(https://github.com/tc39/proposal-decorators)
• member decorators
• class decorators
• built into TypeScript already
enableDecoratorSupport
Decorators in JavaScript

View Slide

• construction logic is essentially listing the dependencies
• goal: get list of constructor parameters
• potential solution: turn class into a string and parse for constructor 
caveat: mangling code changes parameter names 
(remember AngularJS and the dependency list of strings?)
• problem: JS has no types, type information will be lost
Automagic DI with Decorators

View Slide

• there is a way in TypeScript to write type information of decorated classes:
emitDecoratorMetadata
• how to access said metadata?
• JavaScript: part of the decorator proposal
• preliminary implementation
https://www.npmjs.com/package/reﬂect-metadata
Automagic DI with Decorators in TypeScript

View Slide

Let's have a look at some code

View Slide

It's a wrap!
https://thinktecture.com/yannick-baron

View Slide

Hot Topic: Dependency Injection - Let's Talk about it

Hot Topic: Dependency Injection - Let's Talk about it

Yannick Baron

More Decks by Yannick Baron

Other Decks in Programming

Featured

Transcript