european conference

How to decouple your code modules Dependency injection How to decouple your code modules

What is dependency injection? “Put appropriate instances in; don’t let the object create them.” Thanks for your atten… wait, wait, its “a bit” more complicated…

What is SOLID? S - Single responsibility principle (SRP) O - Open/closed principle (OCP) L - Liskov substitution principle (LSP) I - Interface segregation principle (ISP) D - Dependency inversion principle (DIP)

Single responsibility principle A class should only have one responsibility having problems finding a name is a sign of a violation creating things is a responsibility -> factory related to separation of concerns (SoC)

Dependency inversion principle Abstractions should not depend on details. Details should depend on abstractions "Code against interfaces (i.e. abstractions) not implementations (details)"

What is dependency injection "Dependency Injection is a 25-dollar term for a 5- cent concept." "Don't look for things - ask for them!" (Misko Hevery)

Why Dependency Injection? Decoupling of software pieces (classes) SRP flexibility composability exchangeability testability (mocking) maintainability

„To create or not to create“ Injectables and creatables – who is who? Example for creatables: All kinds of collections to store data or inner state (lists, dictionaries, TStrings, dynamic arrays, TStream) PODOs (aka data objects) – but sometimes not directly but with a factory depending on other requirements Injectables are those things that actually do something often called services

Reading suggestions

More material Not only purely on dependency injection but in general useful things about software design and architecture https://blog.ploeh.dk (Blog of Mark Seemann) http://misko.hevery.com/code-reviewers-guide/ (Guide to write testable code) https://www.youtube.com/playlist?list=PL693EFD059797C21E (Google Clean Code Talks)

Pure DI Learn and understand how DI works, what patterns and practices are helpful before using an automated way Try putting your dependencies together manually to get a feeling for how to design your classes and interfaces Once you‘ve written pages and pages of constructor calls, consider using a DI container

Service Locator DI is about passing things (to the constructor basically) Service Locator is about looking for things actively Code smell and dangerous anti-pattern Creates dependencies not only on the service locator but implicitly on types that need to be existing in the service locator Not easily noticable when creating a class but only when some method gets called

Composition root The point where DI starts – ideally there is only one and it‘s at the very start of the application When trying to fit DI into an existing application you might have multiple at first Move them closer to the start of the application and eventually they will converge

DI Container (finally!...) Factory pattern on steroids And a repository, and some other design patterns  A central place to register all your injectables and let them be created and composed automatically

Registering types RegisterType RegisterInstance Tell the container what implementing type is available and as what type it can resolve it Possibility to delegate the creation to another place than the container itself RegisterInstance Tell the container about an existing instance to let it participate in dependency injection

Registering types (advanced) RegisterFactory Register a type and let the container provide its implemention which then serves as factory to return instances returned by the container RegisterDecorator Register a type and let the container use it as decorator for other classes when it resolves them and automatically apply them

Controlling lifetimes New instance every time or use only one? Transient vs Singleton Possibility to control when new instances are being created or already created ones are returned Singleton, SingletonPerThread, PerResolve, Pooled

Type providers Possibility to extend the container to give it special knowledge about specific types and how to build them Examples of built-in providers are: LazyProvider, ListProvider, DynamicArrayProvider

Types of injection Constructor Injection Property Injection constructor parameters mandatory dependencies Property Injection properties/setter optional dependencies Null-Object pattern Field Injection Use only in exceptional cases – this is not possible with pure DI

Controlling the composition Types can be named All injection targets can be marked with the [Inject] attribute to control where and what is being injected Additional conditions can be applied to types and injection targets (planned)

Let‘s take a look at some example

Container.Free