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

You shouldn't have to go out of your way to avoid any pattern. The use of a pattern is either a design decision or a natural fit (it just falls into place). When you are designing a system, you have a choice to either use a pattern or not use the pattern. However, you shouldn't go out of your way to avoid anything that is ultimately a design choice.

I don't avoid the Singleton Pattern. Either it's appropriate and I use it or it's not appropriate and I don't use it. I believe that it is as simple as that.

The appropriateness (or lack thereof) of the Singleton depends on the situation. It's a design decision that must be made and the consequences of that decision must be understood (and documented).

Answer 2

Spring or any other IoC-Container does a reasonably good job in that. Since the classes are created and managed outside the app itself, the container can make simple classes singletons and inject them where needed.

Answer 3

If you're using a Singleton to represent a single data object, you could instead pass a data object around as a method parameter.

(although, I would argue this is the wrong way to use a Singleton in the first place)

Answer 4

What do you mean, what are my techniques to avoid it?

To "avoid" it, that implies that there are many situations that I come across in which the singleton pattern is a naturally good fit, and hence that I have to take some measures to defuse these situations.

But there are not. I don't have to avoid the singleton pattern. It simply doesn't arise.

Answer 5

The singleton pattern exists because there are situations when a single object is needed to provide a set of services.

Even if this is the case I still consider the approach of creating singletons by using a global static field/property representing the instance, inappropriate. It's inappropriate because it create a dependency in the code between the static field and the object not, the services the object provides.

So instead of the classic, singleton pattern, I recommend to use the service 'like' pattern with serviced containers, where instead of using your singleton through a static field, you obtain a reference to it through a a method requesting the type of service required.

*pseudocode* currentContainer.GetServiceByObjectType(singletonType)
//Under the covers the object might be a singleton, but this is hidden to the consumer.

instead of single global

*pseudocode* singletonType.Instance

This way when you want to change type of an object from singleton to something else, you'll have and easy time doing it. Also as an and added benefit you don't have to pass around allot of object instances to every method.

Also see Inversion of Control, the idea is that by exposing singletons directly to the consumer, you create a dependency between the consumer and the object instance, not the object services provided by the object.

My opinion is to hide the use of the singleton pattern whenever possible, because it is not always possible to avoid it, or desirable.

Answer 6

If your issue is that you want to keep state, you want a MumbleManager class. Before you start working with a system, your client creates a MumbleManager, where Mumble is the name of the system. State is retained through that. Chances are your MumbleManager will contain a property bag which holds your state.

This type of style feels very C-like and not very object like - you'll find that objects that define your system will all have a reference to the same MumbleManager.