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.

Lately there have been some kind of revolution against singletons, but is there something wrong with them if they are stateless?

I know the overuse talk and all... this applies to everything not just singletons.

share|improve this question
1  
No. Singletons are in principle not bad, they are just massively overused. –  Bart van Ingen Schenau Jan 4 '13 at 10:22
    
A stateless singleton still suffers an important problem of singletons: it can't easily be replaced for testing. –  Joachim Sauer Jan 4 '13 at 10:28
2  
what do you mean by Lately? –  Manoj R Jan 4 '13 at 10:54
4  
@Joachim Sauer: Why would you need to replace; if it is stateless you can test it dirrectly. –  m3th0dman Jan 4 '13 at 11:06
    
If you have stateless singleton then you basically have a static utility class, which has a tendency of growing into the God Class anti-pattern. You can usually use static methods instead in the context they're used in (or even better: use extension methods in C#). –  Spoike Jan 4 '13 at 11:18
show 7 more comments

4 Answers

up vote 4 down vote accepted
  > Are immutable/stateless singletons bad?
  • No if they do not depend on other external Systems.
    • Example: A Stringutility that escapes html inside a string.
    • Reason: In unittests there is no need to replace this with a mock/simulator.
  • Yes if your immutable/stateless singleton depend on other external Systems/Services and if you want to do unittesting (testing in Isolation)
    • Example: a Service that depends on an External Tax-Calculator-Webservice.
    • Reason: In order to do unittests with this Service (in isolation) you need to simulate/mock the external Systems/Services.

For more details see the-onion-architecture

share|improve this answer
    
You would still have to mock that external web service if you want to test your class, even if it is not a (stateless) singleton. –  m3th0dman Jan 5 '13 at 12:20
add comment

The main problem with singleton is that it hides dependecies and coupling expecially when used in cross-cutting concerns scenario. See Singletons are Pathological Liars or Why Singletons are Evil for further reading.

From the other side, a state less singleton, if not abused, may be helpful and improve performance. Consider an example:

interface Interface
{
    void Method();
}

class StatelessSingleton : Interface
{
    public static readonly StatelessSingleton Instance = new StatelessSingleton();
    private StatelessSingleton() { }

    public void Method() { }
}

class User
{
    public User(Interface i) { /* ... */ }
}

Here, the StatelessSingleton acts as default implementation of the Interface and is put into the User constructor. There is no hard-coded coupling and hiden dependencies. We are unable to use a static class due to the underlying interface but there is no reason to create more than one instance of a default. That's why a stateless singleton seems to be an appropriate choice.

However, maybe we should use another pattern for a default implementation:

class Implementation : Interface
{
    private readonly Action _method;

    public Implementation()
    {
        _method = new Action(() => { /* default */ });
    }

    public Implementation(Action custom)
    {
        _method = custom;
    }

    public void Method()
    {
        _method();
    }
}

It hits the performance with respect to StatelessSingleton but constitutes a generic implementation of the Interface. Similar solution is used by IProgress interface.

Altough again, why allow to create more than one implementation of default behaviour? Yet we can combine the two:

class Implementation : Interface
{
    public readonly Implementation Default = new Implementation();

    private readonly Action _method;

    private Implementation()
    {
        _method = new Action(() => { /* default */ });
    }

    public Implementation(Action custom)
    {
        _method = custom;
    }

    public void Method()
    {
        _method();
    }
}

In conclusion, I believe that there are places (as depicted defaults) where Singletons are useful. The main definition of Singleton states that it disallow to create more than one instance of a class. It's as nuclear power. Can produce an energy or a bomb. It depends on human.

share|improve this answer
add comment

There is nothing an immutable stateless singleton can do that a static class can't.

There is simply no reason to add the extra level of complexity that ->Instance() creates, while plain call to a static method will be clearer, more conservative in terms of resources and probably faster.

It's not that they are wrong. It's that there is a better way to do it. There are scenarios where normal ("stateful") singletons are the right way to go. The evil with singleton is that they are often abused, with same bad results as global variables, but there are specific cases where using a singleton is simply correct. There are none such cases for the stateless ones.

share|improve this answer
    
I bet you can construct some cases where a Singleton has some advantages. Depending on scenario and Programming Language possibly (e.g. taking advantage of lazy loading). –  StampedeXV Jan 4 '13 at 10:31
1  
@StampedeXV: Yes, a stateful singleton certainly. A stateless and immutable one - I'd be really curious to hear any examples but I'm not holding my breath. –  SF. Jan 4 '13 at 10:35
    
Ok, you have a point. I generalized your answer a little there. For immutable stateless I don't see any advantage either. –  StampedeXV Jan 4 '13 at 10:39
1  
With classes that only have static functions, you cannot use inheritance/polymorphism which is a big limit... –  m3th0dman Jan 4 '13 at 11:08
    
Now it becomes fancy. Using Singleton but not knowing the exact type if you want to use inheritance? Still it is a valid use case - and who knows ... –  StampedeXV Jan 4 '13 at 11:30
show 3 more comments

It always depends on the usage. I think the revolution comes from the fact, that every programmer learns this pattern as the object oriented pattern. Most forget to think about where it makes sense and where it doesn't.
This, of course, is true for every pattern. Just by using patterns you don't create good code or good software.

If you have a stateless singleton, why not use a class offering only static methods (or use a static class)?

Here some post regarding global variables and singletons in general.

I wouldn't be as strict as the author but he shows that for most cases where you think you need a singleton, you don't really need it.

share|improve this answer
1  
Why not use a class with static methods? Inheritance for example... –  m3th0dman Jan 4 '13 at 11:07
2  
@m3th0dman: Doesn't sound like a good place for inheritance. –  Billy ONeal Jan 4 '13 at 15:10
    
@BillyONeal You can say that something is good or bad for inheritance if you know the domain model, what is to be modeled in that way... –  m3th0dman Jan 5 '13 at 12:18
1  
@m3th0dman: Erm, no. I can be pretty positive without knowing anything about the domain model. Inheritance is for polymorphic behavior. But as a singleton, you aren't going to have polymorphic behavior. –  Billy ONeal Jan 6 '13 at 1:49
1  
@m3th0dman: Because to get the singleton object requires specifying the name of the singleton at the call site. Which means that you aren't using polymorphic behavior. Which means that composition is far more flexible than inheritance. –  Billy ONeal Jan 6 '13 at 19:29
show 6 more comments

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.