A relation between Dependency Injection, single instance, and singletons

dependency-injection

I read So Singletons are bad, then what? which was a great explanation of dependency injection as the solution for inversion of control. The asker assumed singleton and single instance were synonyms, and as others pointed out singleton is a more restrictive example of single instance.

My question is, why did the responder go from single instance to talking about dependency injection? He states:

A cache does not need to be a singleton. It may need to be a single instance if you want to avoid fetching the same data for multiple cache instances; but that does not mean you actually have to expose everything to everyone.

With DI, you have one interface, in this case "Cache". However, you have multiple instances. Instances of VideoPage + instances of MyAccountPage + etc. VideoPage implements IMediaCache which extends Cache. The DI is that the dependent class that makes use of this caching abstraction does so by using the Cache interface as a type in a parameter list (parameter list of constructor if using constructor injection, etc.)

So there are multiple instances (x VideoPages, y MyAccountPages, etc.) The Cache is the "single" thing in this design pattern, but it's not an instance since you can't instantiate an interface.

"Single instance" and "Dependency Injection" to me are separate ideas, so that response confused me.

I also don't know why people saying dependency injection is an alternative to singletons. A singleton forces one instance even if I try to instantiate again. As for dependency injection, again, what is my "single instance"? The Cache isn't, as I explained earlier. And there are multiple instances of classes ultimately implementing the Cache interface.

Best Answer

Because dependency injection container can and is used for lifetime management. Basically, singleton's main purpose is to maintain lifetime of exactly one instance : it is created once at startup (or first use) and is destroyed when application ends. But if you put both lifetime management and behavior itself in single class (eg. singleton), you break single responsibility principle.

On the other hand, if you have a single top container and use it to manage lifetime of that one instance, based on interface. You can tell you DI container to handle that one implementation of interface as a singleton. So it returns same instance every time it is requested. There are also different lifetimes : per-thread, per-(web)request, etc..

If you use DI instead of static field, then design around this single instance becomes much cleaner. It will also make it easier to change your mind later on, if you realize that what you first thought was a singleton actually isn't.

Related Solutions

Dependency Injection – Dependency Chain Pattern

IMHO creation of "complete" classes via constructor has always been appealing, however setter injection requires a no-arg constructor, allowing pre-conditions (e.g. assertions) to be a reasonable alternative to guarantee "completeness" in the context of DI containers.

To me it is a trade-off between adding complexity versus implementing a simple, pragmatic, solution. And simplicity always wins.

Practical Differences Between Dependency Injection Styles

Constructor Injection has the advantage that it makes the dependency explicit and forces the client to provide an instance. It can also guarantee that the client cannot change the instance later. One (possible) downside is that you have to add a parameter to your constructor.

Setter Injection has the advantage that it doesn't require adding a parameter to the constructor. It also doesn't require the client to set the instance. This is useful for optional dependencies. This may also be useful if you want the class to create, for example, a real data repository by default, and then in a test you can use the setter to replace it with a testing instance.

Interface Injection, as far as I can tell, is not much different than setter injection. In both cases you are (optionally) setting a dependency that can be changed later.

Ultimately it is a matter of preference and whether or not a dependency is required. Personally, I use constructor injection almost exclusively. I like that it makes the dependencies of a class explicit by forcing the client to provide an instance in the constructor. I also like that the client cannot change the instance after the fact.

Often times, my only reason for passing in two separate implementations is for testing. In production, I may pass in a DataRepository, but in testing, I would pass in a FakeDataRepository. In this case I'll usually provide two constructors: one with no parameters, and another that accepts a IDataRepository. Then, in the constructor with no parameters, I will chain a call to the second constructor and pass in a new DataRepository().

Here's an example in C#:


public class Foo
{
  private readonly IDataRepository dataRepository;

  public Foo() : this(new DataRepository())
  {
  }

  public Foo(IDataRespository dataRepository)
  {
    this.dataRepository = dataRepository;
  }
}

This is known as Poor Man's Dependency Injection. I like it because in production client code, I don't need to repeat myself by having several repeated statements that look like

var foo = new Foo(new DataRepository());

However, I can still pass in an alternate implementation for testing. I realize that with Poor Man's DI I'm hardcoding my dependency, but that's acceptable for me since I mostly use DI for testing.

Best Answer

Related Solutions

Dependency Injection – Dependency Chain Pattern

Practical Differences Between Dependency Injection Styles

Related Topic