Edit - Stack Overflow

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome all constructive edits, but please make them substantial. Avoid trivial edits unless absolutely necessary.

Rev

What is dependency injection?

There have been several questions already posted with specific questions about dependency injection, such as when to use it and what frameworks are there for it. However,

What is dependency injection and when/why should or shouldn't it be used?

Answer

**What is Dependency Injection (DI)?**

As others have said, *Dependency Injection(DI)* removes the responsibility of direct creation, and management of the lifespan, of other object instances upon which our class of interest (consumer class) is dependent (in the [UML sense](https://en.wikipedia.org/wiki/Class_diagram#Dependency)). These instances are instead passed to our consumer class, typically as constructor parameters or via property setters (the management of the dependency object instancing and passing to the consumer class is usually performed by an *Inversion of Control (IoC)* container, but that's another topic).

**DI, DIP and SOLID**

Specifically, in the paradigm of Robert C Martin's [SOLID principles of Object Oriented Design](http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)), `DI` is one of the possible implementations of the [Dependency Inversion Principle (DIP)](http://en.wikipedia.org/wiki/Dependency_inversion_principle). The [DIP is the `D` of the `SOLID` mantra](http://stackoverflow.com/q/27978841/314291)  - other DIP implementations include the Service Locator, and Plugin patterns.

The objective of the DIP is to decouple tight, concrete dependencies between classes, and instead, to loosen the coupling by means of an abstraction, which can be achieved via an `interface`, `abstract class` or `pure virtual class`, depending on the language and approach used.

Without the DIP, our code (I've called this 'consuming class') is directly coupled to a concrete dependency and is also often burdened with the responsibility of knowing how to obtain, and manage, an instance of this dependency, i.e. conceptually:

"I need to create/use a Foo and invoke method `GetBar()`"

Whereas after application of the DIP, the requirement is loosened, and the concern of obtaining and managing the lifespan of the `Foo` dependency has been removed:

"I need to invoke something which offers `GetBar()`"

**Why use DIP (and DI)?**

Decoupling dependencies between classes in this way allows for *easy substitution* of these dependency classes with other implementations which also fulfil the prerequisites of the abstraction (e.g. the dependency can be switched with another implementation of the same interface). Moreover, as others have mentioned, possibly *the* most common reason to decouple classes via the DIP is to allow a consuming class to be tested in isolation, as these same dependencies can now be stubbed and/or mocked.

One consequence of DI is that the lifespan management of dependency object instances is no longer controlled by a consuming class, as the dependency object is now passed into the consuming class (via constructor or setter injection).

This can be viewed in different ways:

- If lifespan control of dependencies by the consuming class needs to be retained, control can be re-established by injecting an (abstract) factory for creating the dependency class instances, into the consumer class. The consumer will be able to obtain instances via a `Create` on the factory as needed, and dispose of these instances once complete.
 - Or, lifespan control of dependency instances can be relinquished to an IoC container (more about this below).

**When to use DI?**

- Where there likely will be a need to substitute a dependency for an equivalent implementation, 
 - Any time where you will need to unit test the methods of a class in isolation of its dependencies, 
 - Where uncertainty of the lifespan of a dependency may warrant experimentation (e.g. Hey, `MyDepClass` is thread safe - what if we make it a singleton and inject the same instance into all consumers?)

**Example**

Here's a simple C# implementation. Given the below Consuming class:

public class MyLogger
    {
       public void LogRecord(string somethingToLog)
       {
          Console.WriteLine("{0:HH:mm:ss} - {1}", DateTime.Now, somethingToLog);
       }
    }

Although seemingly innocuous, it has two `static` dependencies on two other classes, `System.DateTime` and `System.Console`, which not only limit the logging output options (logging to console will be worthless if no one is watching), but worse, it is difficult to automatically test given the dependency on a non-deterministic system clock.

We can however apply `DIP` to this class, by abstracting out the the concern of timestamping as a dependency, and coupling `MyLogger` only to a simple interface:

public interface IClock
    {
        DateTime Now { get; }
    }

We can also loosen the dependency on `Console` to an abstraction, such as a `TextWriter`. Dependency Injection is typically implemented as either `constructor` injection (passing an abstraction to a dependency as a parameter to the constructor of a consuming class) or `Setter Injection` (passing the dependency via a `setXyz()` setter or a .Net Property with `{set;}` defined). Constructor Injection is preferred, as this guarantees the class will be in a correct state after construction, and allows the internal dependency fields to be marked as `readonly` (C#) or `final` (Java). So using constructor injection on the above example, this leaves us with:

public class MyLogger : ILogger // Others will depend on our logger.
    {
        private readonly TextWriter _output;
        private readonly IClock _clock;

// Dependencies are injected through the constructor
        public MyLogger(TextWriter stream, IClock clock)
        {
            _output = stream;
            _clock = clock;
        }

public void LogRecord(string somethingToLog)
        {
            // We can now use our dependencies through the abstraction 
            // and without knowledge of the lifespans of the dependencies
            _output.Write("{0:yyyy-MM-dd HH:mm:ss} - {1}", _clock.Now, somethingToLog);
        }
    }

(A concrete `Clock` needs to be provided, which of course could revert to `DateTime.Now`, and the two dependencies need to be provided by an IoC container via constructor injection)

An automated Unit Test can be built, which definitively proves that our logger is working correctly, as we now have control over the dependencies - the time, and we can spy on the written output:

[Test]
    public void LoggingMustRecordAllInformationAndStampTheTime()
    {
        // Arrange
        var mockClock = new Mock<IClock>();
        mockClock.Setup(c => c.Now).Returns(new DateTime(2015, 4, 11, 12, 31, 45));
        var fakeConsole = new StringWriter();

// Act
        new MyLogger(fakeConsole, mockClock.Object)
            .LogRecord("Foo");

// Assert
        Assert.AreEqual("2015-04-11 12:31:45 - Foo", fakeConsole.ToString());
    }

**Next Steps**

Dependency injection is invariably associated with an [Inversion of Control container(IoC)](http://martinfowler.com/articles/injection.html), to inject (provide) the concrete dependency instances, and to manage lifespan instances. During the configuration / bootstrapping process, `IoC` containers allow the following to be defined:

- mapping between each abstraction and the configured concrete implementation (e.g. *"any time a consumer requests an `IBar`, return a `ConcreteBar` instance"*)
  - policies can be set up for the lifespan management of each dependency, e.g. to create a new object for each consumer instance, to share a singleton dependency instance across all consumers, to share the same dependency instance only across the same thread, etc.
  - In .Net, IoC containers are aware of protocols such as `IDisposable` and will take on the responsibility of `Disposing` dependencies in line with the configured lifespan management.

Typically, once IoC containers have been configured / bootstrapped, they operate seamlessly in the background allowing the coder to focus on the code at hand rather than worrying about dependencies.

> The key to DI-friendly code is to avoid static coupling of classes, and not to use new() for the creation of Dependencies

As per above example, decoupling of dependencies does require some design effort, and for the developer, there is a paradigm shift needed to break the habit of `new`ing dependencies directly, and instead trusting the container to manage dependencies.

But the benefits are many, especially in the ability to thoroughly test your class of interest.

**Note** : The creation / mapping / projection (via `new ..()`) of POCO / POJO / Serialization DTOs / Entity Graphs / Anonymous JSON projections et al - i.e. "Data only" classes or records - used or returned from methods are *not* regarded as Dependencies (in the UML sense) and not subject to DI. Using `new` to project these is just fine.

Edit Summary

cancel

current community

your communities

more stack exchange communities

What is dependency injection?

Answer

How to Edit

How to Format

How to Tag