The Singleton Pattern

I stumbled upon the singleton pattern while reading a PHP book and fell in love with its simplicity. I rushed to use it at every single opportunity I got (when you have a hammer, everything looks like a nail, right?) until I got tired of it; now I can’t really remember when I used it last. Why? Well, there has been no reason to. Singletons have been the topic of heated debates over time, some people even consider them to be an anti-pattern! But first, what is this pattern all about?

The Singleton pattern is a design pattern that ensures that only one object of a class exists. Singletons are best used when you need to have a single object control simultaneous access to shared resources by other objects. If this conditions are not met, you should consider another design.

So how do I create a Singleton?

Blosch in Effective Java listed these two ways: exposing a member variable and using a static factory.

Using a public member variable

public class Singleton {

public static final Singleton instance = new Singleton()

private Singleton() {…}

//other code

}

Using a static Factory

public class Singleton{

private static final Singleton instance = new Singleton()

private Singleton() {…}

public static Singleton getInstance(){

if (instance == null)

instance = new Singleton()

return instance

}

//other code

}

Why are Singletons used?

A good application of Singletons is in logging; you’ll probably want to log all events from the various classes in your project to a single location. So it is best to use a singleton to write, synchronize writes and close the file. They can also be used to read static configuration files at startup and provide all other classes with initialization details.

Great! So why the fuss about Singletons? Well, Singletons (like all other misuses occurring in software engineering) are not the problem; people are. When used by people without a strong grasp of OO concepts, they can turn into humongous monstrosities that cause unnecessary restrictions and bring in global state. Worse still, they’ll be used when they is absolutely no need for them or what they were not designed to do.

Enough talk about ugly code… Here are some of the issues:

• Memory Management: How does garbage collection occur? Well no one knows that the single instance has not been used for a long loooong loooooooooooong time. And how do you know if some remote class has a reference to the single instance?

• Singletons are hard to subclasss; it is pretty difficult to override the default initialization sequence.

• Worse still, try handling multithreaded singletons.

• It is difficult to test Singletons and they can cause code to become tightly coupled.

So you might thinking Singletons are evil now; no not quite. Singletons pros include:

• Singletons can implement interfaces and inherit from other classes.

• They can be lazy-loaded (most times they are); this is great for expensive resources.

• They can be easily converted into factories.

Should I use a Singleton?

I have only one thing to say; Learn about it well enough else you’ll be using a hammer to drive in a pin!