Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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);

    singConsumer.ConsumerAdd(10,20);

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?

share|improve this question

migrated from stackoverflow.com Dec 24 '11 at 5:25

This question came from our site for professional and enthusiast programmers.

    
Can you please tell me how DI can replace the singleton? –  logeeks Dec 23 '11 at 19:38
6  
Singleton is a design pattern. DI/IoC is a technique. –  Dave Dec 23 '11 at 19:39
1  
DI cannot replace Singleton any more than a banana could replace a carburetor. They're completely different concepts. –  Dave Dec 23 '11 at 19:39
    
so my example is valid. –  logeeks Dec 23 '11 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 '11 at 19:49

4 Answers 4

up vote 11 down vote accepted

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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