current community

your communities

more stack exchange communities

company blog
Stack Exchange Inbox Reputation and Badges
tour help
Join the Stack Overflow Community
Stack Overflow is a community of 6.6 million programmers, just like you, helping each other.
Join them; it only takes a minute:
Sign up
up vote 5 down vote favorite
1

I have a singleton that depends on another class so I'd like to inject this dependency in order to make it unit-testable. Since there's no way to use constructor injection on the singleton I guess I should use setter injcetion instead but I really don't like it since at some point someone (probably myself) will forget to call the setter. You could of course inject the dependent objects to the singleton's getInstance method but this is pretty ugly as well. Are there some better ways of solving this (not using tools like IoC containers)?

public class Singleton {
    private ISomeDependency _dependency;
    private static final Singleton INSTANCE = new Singleton();
    private Singleton() {
    }
    public static Singleton getInstance() {
       return INSTANCE;
    }
    ...
}
share|improve this question
1  
Good question. But I do hope you embrace the answers that steer you away from doing what you want above. – Johann Gerell May 26 '11 at 8:08
up vote 3 down vote accepted

The singleton design pattern is a big anti-pattern, because there is no way to inject dependencies in a singleton. This doesn't mean however, that there is no way to have a single instance during the lifetime of the application, but you shouldn't use the singleton design pattern for this. Especially when using dependency injection, there is no reason to use this design pattern.

Just inject an instance of that type as constructor in the types that depend upon it and you're done. This gives you the possibility to build up the object graph in the top of your application and control the lifestyle there and inject dependencies into that instance.

The design of that class should just like any other class:

public class SomeService : ISomeService 
{
    private ISomeDependency _dependency;

    public ISomeService(ISomeDependency dependency)
    {
        _dependency = dependency;
    }

    // ISomeService members here
}

A dependency injection framework will allow you to define the lifestyle of any type very easily. For simple applications, you can however still do this by hand.

share|improve this answer
    
Thanks for the answer. But I don't get how to make absolutely sure that there's only one instance of the class if not using the Singleton pattern? Since the constructor will have to be public anyone can create an instance of it anywhere. – Christian May 26 '11 at 8:02
    
Really, Amen to that! – Johann Gerell May 26 '11 at 8:03
    
@Christian: That's the whole point of only instantiating dependencies at the composition root, i.e., the application top, like Main() for example. Of course you can instantiate a dependency at other places, but if you make a habit of never doing it (other than from factories etc.), then the world will be a greener place to live in :) For example, you can always ::memset() arbitrary memory to garbage anywher in a C app, but that doesn't make it correct. – Johann Gerell May 26 '11 at 8:07
    
@Johann: yes I'm only looking for a way of minimizing the risk of using the solution wrongly and maximizing the chance of using it correctly. In a real-world project there's always going to be someone using the code in a way that is not intended. In the suggested solution you be absolutely certain that someone at some point will create their own instance of the class which is supposed to act as a singleton. – Christian May 26 '11 at 8:14
1  
@Christian: Then that's a symptom of bigger problems. If code reviews are working and the team has an agreed-upon over-all design methodology, then it should come as no surprise that service dependencies are not instantiated on their own. That is, if DI is actually used in the first place. – Johann Gerell May 26 '11 at 8:24
up vote 0 down vote

You can use a dependency injection container (like Spring.Net, MS Unity, etc.) to get the concrete type of your dependency.

public class Singleton {
private ISomeDependency _dependency = Container.Resolve<ISomeDependency>();
private static final Singleton INSTANCE = new Singleton();
private Singleton() {
}
public static Singleton getInstance() {
   return INSTANCE;
}
...
}

Now you have the control outside of the singleton.

share|improve this answer
    
Thanks. However I'd like to know what's the preferred way of solving this without the use of any IoC containers. I'll edit my question. – Christian May 26 '11 at 8:23
    
This way you'll have a hard dependency on your container, which makes it hard to write unit tests. You should always prefer using the depedency inection pattern over the service locator pattern. – Steven May 26 '11 at 9:24

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.