I've been hearing about using the dependency injection over Singleton for my colleague. I still can't make out if it they are two orthogonal patterns which can be replaced with one another? Or is DI a method to make the Singleton pattern testable?

Please take a look at the following code snippet.

    IMathFace obj = Singleton.Instance;

    SingletonConsumer singConsumer = new SingletonConsumer(obj);


The SingletonConsumer is accepting a parameter of type IMathFace. Instead of accessing the singleton class internally, SingletonConsumer will get the singleton instance passed by the caller. Is this a good example of consuming singleton class via dependency injection?

  • Can you please tell me how DI can replace the singleton?
    – logeeks
    Dec 23, 2011 at 19:38
  • 8
    Singleton is a design pattern. DI/IoC is a technique.
    – Dave
    Dec 23, 2011 at 19:39
  • 2
    DI cannot replace Singleton any more than a banana could replace a carburetor. They're completely different concepts.
    – Dave
    Dec 23, 2011 at 19:39
  • so my example is valid.
    – logeeks
    Dec 23, 2011 at 19:39
  • 1
    Yes, but it may come on the expense of encapsulation (which is also true for non-singleton) see: stackoverflow.com/questions/1005473/…
    – Amittai Shapira
    Dec 23, 2011 at 19:49

4 Answers 4


I think he meant that you should use dependency injection to inject a single instance of the service, instead of using the classical Singleton implementation with a static accessor MySingleton.Instance.

public class MySingleton
    public static MySingleton Instance{get{...}};

With the classical singleton implementation all your code depends on that service being a singleton. You basically hardcode that assumption into consuming code whenever you use MySingleton.Instance.

On the other hand with DI you get an instance of the service passed into your constructor, and store it. That there is only a single instance of this service is an implementation detail. You can easily change it to give the consuming code a different instance. That way you have some class/interface which happens to be implemented by a single instance, instead of enforcing that there is only one instance.

This is useful if you for example want a mock implementation of the service for testing, or if different parts of the program need different configurations of that service.


There is one case where the Singleton pattern and DI/IoC intersect- the injection of a Singleton.

Most DI frameworks can be configured to instantiate a single instance of an injected object. Any consumer object that requests an instance of such an object will get the same single instance. That instance is by definition a Singleton. That's about it for the overlap in concept.


Yes, you are right. Instead of accessing the object via the singleton, you are passing a reference to it thus you're using a constructor injection.

What others point out is that these notions are not related. Consuming a singleton instance is nothing special as the object you are injecting to doesn't really care where the injected object comes from.


The confusion here is that two concepts have been conflated: the singleton and the static accessor/gateway to the singleton instance.

As you have rightly identified, your colleague is suggesting that the dependency be injected rather than accessed directly using Singleton.Instance (static gateway).

The reason that this has nothing really to do with the singleton pattern is that the same DI concept applies equally to instantiating a non-singleton object with new Foo(). The dependency would be injected irrespective of whether it is a singleton implementation.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.