Are there any viable alternatives to the GOF Singleton Pattern?

Question

Let\'s face it. The Singleton Pattern is highly controversial topic with hordes programmers on both sides of the fence. There are those who feel like the Singleto

Answer 1

Having not programmed in an intensely object-oriented environment (e.g. Java), I'm not completely up on the intricacies of the discussion. But I have implemented a singleton in PHP 4. I did it as a way of creating a 'black-box' database handler that automatically initialized and didn't have to be passed up and down function calls in an incomplete and somewhat broken framework.

Having read some links of singleton patterns, I'm not completely sure I would implement it in quite the same way again. What was really needed was multiple objects with shared storage (e.g. the actual database handle) and this is pretty much what my call turned into.

Like most patterns and algorithms, using a singleton 'just because it's cool' is The Wrong Thing To Do. I needed a truly 'black-box' call that happened to look a lot like a singleton. And IMO that's the way to tackle the question: be aware of the pattern, but also look at it's wider scope and at what level it's instance needs to be unique.

Answer 2

Monostate (described in Robert C. Martin's Agile Software Development) is an alternative to singleton. In this pattern the class's data are all static but the getters/setters are non-static.

For example:

public class MonoStateExample
{
    private static int x;

    public int getX()
    {
        return x;
    }

    public void setX(int xVal)
    {
        x = xVal;
    }
}

public class MonoDriver
{
    public static void main(String args[])
    {
        MonoStateExample m1 = new MonoStateExample();
        m1.setX(10);

        MonoStateExample m2 = new MonoStateExample();
        if(m1.getX() == m2.getX())
        {
            //singleton behavior
        }
    }
}

Monostate has similar behavior to singleton but does so in a way where the programmer is not necessarily aware of the fact that a singleton is being used.

Answer 3

Actually if you design right from scratch on avoiding Singeltons, you may not have to work around not using Singletons by using static variables. When using static variables, you are also creating a Singleton more or less, the only difference is you are creating different object instances, however internally they all behave as if they were using a Singleton.

Can you maybe give a detailed example where you use a Singleton or where a Singleton is currently used and you are trying to avoid using it? This could help people to find a more fancy solution how the situation could be handled without a Singleton at all.

BTW, I personally have no problems with Singletons and I can't understand the problems other people have regarding Singletons. I see nothing bad about them. That is, if you are not abusing them. Every useful technique can be abused and if being abused, it will lead to negative results. Another technique that is commonly misused is inheritance. Still nobody would say inheritance is something bad just because some people horribly abuse it.

Answer 4

I use singleton mostly as "methods container", with no state at all. If I need to share these methods with many classes and want to avoid the burden of instantiation and initialization I create a context/session and initialize all the classes there; everything which refers to the session has also access to the "singleton" thereby contained.