Most common examples of misuse of singleton class

Question

When should you NOT use a singleton class although it might be very tempting to do so? It would be very nice if we had a list of most common instances of \'singletonitis\' t

Answer 1

In the case of a connection (for instance), it makes sense that you wouldn't want to make the connection itself a singleton, you might need four connections, or you may need to destroy and recreate the connection a number of times.

But why wouldn't you access all of your connections through a single interface (i.e. connection manager)?

Answer 2

One of the things that tend to make it a nightmare is if it contains modifiable global state. I worked on a project where there were Singletons used all over the place for things that should have been solved in a completely different way (pass in strategies etc.) The "de-singletonification" was in some cases a major rewrite of parts of the system. I would argue that in the bigger part of the cases when people use a Singleton, it's just wrong b/c it looks nice in the first place, but turns into a problem especially in testing.

Answer 3

When you have multiple applications running in the same JVM.

A singleton is a singleton across the entire JVM, not just a single application. Even if multiple threads or applications seems to be creating a new singleton object, they're all using the same one if they run in the same JVM.

Answer 4

Sometimes, you assume there will only be one of a thing, then you turn out to be wrong.

Example, a database class. You assume you will only ever connect to your app's database.

// Its our database! We'll never need another
class Database
{
};

But wait! Your boss says, hook up to some other guys database. Say you want to add phpbb to the website and would like to poke its database to integrate some of its functionality. Should we make a new singleton or another instance of database? Most people agree that a new instance of the same class is preferred, there is no code duplication.

You'd rather have

Database ourDb;
Database otherDb;

than copy-past Database and make:

// Copy-pasted from our home-grown database.
class OtherGuysDatabase
{
};

The slippery slope here is that you might stop thinking about making new instance of classes and instead begin thinking its ok to have one type per every instance.

Answer 5

Do not use a singleton for something that might evolve into a multipliable resource.

This probably sounds silly, but if you declare something a singleton you're making a very strong statement that it is absolutely unique. You're building code around it, more and more. And when you then find out after thousands of lines of code that it is not a singleton at all, you have a huge amount of work in front of you because all the other objects expect "the" sacred object of class WizBang to be a singleton.

Typical example: "There is only one database connection this application has, thus it is a singleton." - Bad idea. You may want to have several connections in the future. Better create a pool of database connections and populate it with just one instance. Acts like a Singleton, but all other code will have growable code for accessing the pool.

EDIT: I understand that theoretically you can extend a singleton into several objects. Yet there is no real life cycle (like pooling/unpooling) which means there is no real ownership of objects that have been handed out, i.e. the now multi-singleton would have to be stateless to be used simultaneously by different methods and threads.

Answer 6

Singletons are virtually always a bad idea and generally useless/redundant since they are just a very limited simplification of a decent pattern.

Look up how Dependency Injection works. It solves the same problems, but in a much more useful way--in fact, you find it applies to many more parts of your design.

Although you can find DI libraries out there, you can also roll a basic one yourself, it's pretty easy.