> 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

• Singleton-s can make unit-testing (in isolation) more difficuilt/impossible and
• hidden dependecies/coupling can be sees as a problem as explained by @yBee

I donot see other reasons why not using Singletons.

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.

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.

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.

Some time ago I changed my definition. You shouldn’t care about “singleton classes” but “singleton objects”, defined as an object that has one specific purpose, that can be accessed from anywhere in your code base, and that exists or is created when it is needed and stays in existence forever. I don’t care about the class. I don’t care if the class has multiple instances, I just care that there is one specific instance that I use.

Some code of mine might have a variable where it stores this singleton object when created, or the singleton object may be passed in at creation time, that doesn’t make a difference.

And since there is only one, it is obvious that any change of state affects everything. That’s something you need to be aware of. It is neither good nor bad. It may be what you want. If not, you will need to use locking. For example, a translator object with properties “source language” and “destination language” will cause problems.

When you have a singleton that is completely stateless, then what you actually have is an utility class that’s nothing but a collection of idempotent functions. One of those typical “toolbox” classes that contain a bunch of utility methods used by other classes.

So why not make it a class with only static methods? That saves you all the overhead of managing the singleton instance.