Dependency Inversion Principle

Depend on abstractions, not on concretions.

Shahriar HyderKaz Software Ltd.29th September, 2011

Dependency Inversion Principle

In object-oriented programming, the dependency inversion principle refers to a specific form of decoupling where conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are inverted (i.e. reversed) for the purpose of rendering high-level modules independent of the low-level module implementation details. The principle states:

Dependency Inversion Principle

High level modules should not depend on low level modules. Both should depend on abstractions.

Abstractions should not depend on details. Details should depend on abstractions.

Depend on abstractions, not on concretions

Inversion of control

In software engineering, Inversion of Control (IoC) is an abstract principle describing an aspect of some software architecture designs in which the flow of control of a system is inverted in comparison to procedural programming.

Inversion of control

Also known as the Hollywood Principle Don’t call us, we’ll call you!

Objects rely on their environment to provide dependencies rather than actively obtaining them.

Inversion of Control can make the difference between a library and a framework.

Dependency Injection

Dependency injection (DI) is a design pattern in object-oriented computer programming whose purpose is to reduce the coupling between software components. It is similar to the factory method pattern. Frequently an object uses (depends on) work produced by another part of the system. With DI, the object does not need to know in advance about how the other part of the system works. Instead, the programmer provides (injects) the relevant system component in advance along with a contract that it will behave in a certain way.

Dependency Injection

Dependency injection is = IoC + Dependency Inversion: Dependencies are provided externally so we

enforce the dependency inversion principle The container sets the dependencies (not us)

so we speak of inversion of control Aspect-oriented programming is one

technique to implement IoC. Dependency Injection - one example of

IoC design principle.

The Service Locator Pattern

The service locator pattern is a design pattern used in software development to encapsulate the processes involved in obtaining a service with a strong abstraction layer. This pattern uses a central registry known as the "service locator" which on request returns the information necessary to perform a certain task.

The Service Locator Pattern

For some reasons many people think that there is no relationship between Service Locator and DI. The Service Locator is yet another implementation of the Dependency Inversion Principle. And yes Service Locator is competitor for the Dependency Injection Pattern! But they still can co-exist.

Plugin

 Use your brains!

DIP Violations

Use of “new”

DIP Violations

Use of “static”

public class SecurityService{ public static User GetCurrentUser() { // do something }}

DIP Violations

Use of singletons using “static”

public class ProductCache{ private static readonly _instance = new ProductCache(); public static ProductCache Instance { get { return _instance; } }}

What is a DI (IoC) Container? Creates objects that are ready for you to use Knows how to create objects and their

dependencies Knows how to initialize objects when they are

created (if necessary) Provide lifecycle support A container is nothing more than a fancy

dictionary of interfaces and their implementing types

Inversion Of Control containers act like “super factories”

DI Containers

Spring Framework Unity (Microsoft) Windsor (Castle Project) Ninject StructureMap

Types of Dependency Injection

Constructor (Most popular) Setter Method

Type 1 or interface injection / Method Injection

Injecting a ICustomerRepository as well as an integer dependency.

Type 2 or Setter Injection

Injecting a ICustomerRepository through the setter.

Type 3 or Constructor Injection

Injecting a ICustomerRepository and a ICustomerDTOMapper through the constructor.

Note: This is the most popular type of injection.

Dependency Injection Pros & Cons

Pros Loosely Coupled Increases Testability (A LOT!) Separates components cleanly Allows for use of Inversion of Control Container

Cons Increases code complexity Some Jr. Developers find it difficult to understand at First Can Complicate Debugging at First Complicates following Code Flow Architecture is less straight-forward Overkill for smaller or throwaway applications Easy to abuse Be careful to avoid “XML Hell” in configuration files

*ILITIES

Agility Testability Reversibility Changeability Flexibility Maintainability

Resource

Probably the best place to read is Martin Fowler - Inversion of Control Containers and the Dependency Injection pattern