Are there cases where a singleton is the best option?

Question

There is a lot of discussion on this site about why singletons should be avoided but are there any cases where a singleton makes sense and is the best option?

An example where I think that a singleton is the best option is when implementing an Identity Map where you need to keep track of all models that have already been loaded from the database in your mapping layer. In this case it is important that the map is effectively global so that all client code uses the same instance of the map and they are all accessing the same list of loaded models. The simplest solution seems to be to implement the class as a singleton (or as static methods). Is this the best approach or is there another way?

Are there any other cases where it is OK to use a singleton or are they always bad?

Answer 1

There is a use for singletons (and similar) in languages that don't allow static interface members - such as in .NET. By providing a singleton, you have an instance that can provide the interface as an instance. So in .NET, examples might be:

• Comparer<T>.Default - provides an IComparer<T> implementation for sorting T
• EqualityComparer<T>.Default - provides an IEqualityComparer<T> implementation for hashing/equality-testing T

This is as a means-to-an-end; it isn't what we are trying to do, just a reasonable "how".

In terms of the "identity map" example, personally I would rather keep that on an instance, and make the instance available to all my code. Apart from anything else, it aids testability if you can discard the map between tests, or have the flexibility (later) to have multiple identity maps at the same time.

Answer 2

Think of case where you would like to log different events in the application to a single file. In that case a singleton class Log will be useful. Since different part of the application will be accessing the same instance of the Log class.

Answer 3

See this thread.

Answer 4

Singletons do have their uses. They have their abuses too, and there are lots of reasons to not like them or why they make testing difficult.

Here's a small defence of the Singleton pattern.

Sometimes, a program needs to represent or interact with something that is truly singular. An example is a physical resource. You can't have more than one 'stdout', for example. And the representation of the OS process (e.g. J2ME's Midlet).

Singletons as in using class/interface to give encapsulation and such benefits to what would otherwise be a naked global variable is worth it.

Answer 5

Singletons make sense when you're using web programming: you generally only ever want one instance of a page output class per request, and one user object for it. Databases are different though - implementing privilege separation is a good reason for wanting more than one db object.

Answer 6

My personal guideline is to never hardcode a class as a singleton if you can just instantiate one object of a class afterwards. This makes singletons very rare and often unnecessary in application code. This is especially true when using DI frameworks like Spring.

Singletons do have a use as 'entry points' in frameworks, but there the rule would be to use them as 'root singletons' (at the start of the dependency hierarchy) and let the rest of the code depend on that singleton as little as possible.

Answer 7

Singletons do indeed have their uses. I would summarize their usefulness as:

"A Singleton should be used to represent on object of which, according to the fundamental design or requirements, there can be at most one instance; and there is data or resources associated with the object which incurs a measurable cost." Here's what I mean.

1) You shouldn't use a Singleton in the case where there are many of something, but we only happen to be interested in one. If there could conceivably be two in the system, instantiate one explicitly.

2) Many uses of a Singleton can be replaced by a class with all static methods and data. If you can do this without performance penalty, do it.

3) You should consider a Singleton if there is a noticeable cost to setting up the object: for example if it's a physical resource which needs to be initialized, or it relies on some lookup table that needs to be initialised. If that is the case, with a Singleton you can defer the initialisation cost until the first use of the object, whereas a static class will usually initialise on app start. If the object is never used you never pay the initialisation cost.

Answer 8

Singletons should be used when you need only one instance and want to enforce that through design. It shouldn't be used because of the global side effect it causes.

In your case, I think that makes sense because you want to limit only one instance of the class.