About me

Elias Zerrouq (mail@eliaszerrouq.nl)

(freelance) (web-)developer from the Netherlands studying

computer science

run the magenticians.com blog (twitter @magenticians)

first time in Italy

Comprehension is important

Understanding dependency injection is more

important than memorizing the usage of it by an

implementing platform, for example Magento 2.

You might look at this...

...and think “Blergh, this looks ugly but all core

files work like this, so I better copy it!”

You are now using dependency injection but

have no idea how or why it works.

It’s not just dependency injection

By understanding “how” and “why” things work,

you distance yourself from those who don’t.

Given the size and amount of all systems, it’s

not realistic to understand everything of every

system.

Where does dependency injection

come from?

Dependency injection is a form of inversion

of control and an implementation of

dependency inversion.

The specific term “dependency injection” is

coined by Martin Fowler and “various IoC

advocates”[1].

[1] “Inversion of Control Containers and the Dependency Injection pattern”, 23 January

2004 by Martin Fowler

Inversion of dependency control…

what?

Inversion of Control traditionally means that

instead of calling a component its methods,

endpoints are registered with the component and

called when needed.

In general, control being inversed is the flow of

the program.

An example of inversion of control

Instead of having a sequential approach to

routing a request, the request is processed by

one or many routers.

Components should rely on abstractions and

not on specific implementations. Depending on

details results in tightly coupled components.

● High level modules should not depend upon low-level modules. Both

should depend upon abstractions.

● Abstractions should never depend upon details. Details should depend

upon abstractions.

Dependency Inversion

Part of SOLID

S Single responsibility principle

O Open/closed principle

L Liskov substitution principle

I Interface segregation principle

D Dependency inversion principle

An example of dependency inversion

In Magento 1.X, Zend_Mail is an hard wired

dependency:

In Magento 2, this is solved by relying on abstractions for sending email.

Looking back at the previous

example

Everything is abstract. No details about implementation of

● request

● router list

● router

● resulting action instance

Advantages

● Everything is loosely coupled which allows

for modification of the one without impacting

the other.

● Individual components are easily testable.

● Code reuse.

● You only need to know what to supply and

what you get back.

Disadvantages

Everything. Is. Abstract.

● Complexity increases.

● Thus more time required initially.

● Pre-mature abstraction.

● Overhead.

Dependency injection

By relying on abstractions, at some point you

need to supply or leverage an actual

implementation (like Zend_Mail).

This is where dependency injection comes in.

So what dependency injection

means

By using dependency inversion, any

component can have dependencies it needs

to function. To make sure the dependent can

function, the dependencies are injected into

the dependent.

The exact implementation of those

dependencies are picked at runtime.

Common dependency injection

approaches

● Dependencies are passed during

construction of the object

● Dependencies are passed via (magic)

setters

● Dependencies are directly set to object

properties

So what about Magento 2?

● Magento 2 uses constructor injection

● It rolls a custom dependency injection

framework

● It uses XML configuration

Constructor Injection

Common misconception

The amount of times you need to do this:

new Handler(new Dependency(

new SubDependency($argument)),new SecondDepency($data)…………

);

...is probably zero.

Dependency injection can be

automated

Most dependency injection frameworks use

recursive reflection and/or pre-defined

configuration to determine which

implementations of the dependencies should

be injected.

Magento 2 does this too.

Magento 2 its di.xml allows

● Type hinted interface argument preferences

● Constructor arguments

● Deferred creation of dependencies by

proxies

● Automatic creation of utility classes

(factories, repositories)

● Plugin definitions

● Constants for object configuration

Example A: constructor argument

Service Contracts are possible due

to dependency injection

Service contracts define a pair of recurring

interface sets which separates consumer from

implementation.

Because the consumer knows nothing about

how the service works, only what it has to

supply or gets back, the underlying

implementation can change without affecting

consumers.

Example B: interface implementation

preference

In many modules, all service contracts have a

preference to a default implementation supplied by

Magento.

Some things cannot be injected

Everything which has an identity (i.e. an object

representing a database entry) cannot be

directly injected. For those, factories should be

used.

Magento 2 its code generation mechanics allow

simple factories to be created with zero

configuration.

Configuration allows change

In Magento 2, each module can supply different

implementations and arguments for

dependencies used by the application.

This allows to easily change behavior without

touching or rewriting core classes.

Summarized

It’s all for the better.

If there is any time left, are there any questions?