The Singleton Pattern

A design pattern is a general solution for a common problem in software design. The idea is that the solution gets translated into code and applied in different situations where the problem occurs.

One of the commonly used creational patterns is the Singleton pattern. It describes a technique for ensuring that only a single instance of a class is ever created. The technique takes the following approach: don’t let anyone outside the class create the instance of the class. Typically, singletons are created to reduce the memory requirements. You can implement this approach in many different ways.

One of the ways is to make the constructor of the class private or protected and providing a static method which returns an object of the class. By this you can guarantee that only one instance is shared among all. Also, if you know the one instance being created will be the subclass, make the parent class abstract and provide a method to get the current instance. Similar ways of restricting class creation can be found throughout the J2SE standard libraries.

At this point you might think that restricting access to a constructor automatically makes it a Singleton. It doesn’t. An example for that is the Calendar class. The Calendar class constructor is protected, and the class offers a getInstance () method to get an instance of the class. However, each call to getInstance () method gets a new instance of the class. So that is not singleton.

When you create your own Singleton class, make sure that only one instance is ever created:

public class MySingleton{
    private static final MySingleton INSTANCE = new MySingleton ();
    private MySingleton () { }
    public static final MySingleton getInstance() {
        return INSTANCE;

The static method, getInstance (), returns the single instance of the class. Note that even if the single instance needs to be a subclass, you don’t have to change the API.

Theoretically, you don’t need the getInstance () method because the INSTANCE variable could be public. However, the getInstance () method provides the flexibility in case of future system changes.

The Singleton pattern is useful if you know you only have a single resource, and need to share access to the state information of that single instance. Identifying the need for the Singleton pattern at design time can simplify development. However, some times you are not aware of the need until a performance problem leads you to refactor code and use the pattern at a later time. For example, you might discover that system performance is degrading because your program is creating instances of the same class to pass the state information. By changing to the Singleton pattern, you avoid recreating the same object. This frees up time the system uses to recreate the object, and saves the time the garbage collector needs to free those instances.

In short, use the Singleton pattern when you want to ensure that one, and only one, instance of the class is ever created. If your constructor doesn’t require any operations, provide an empty private constructor (or a protected constructor if you need to subclass). Otherwise, by default, the system will provide a public constructor, something you don’t want when working with a Singleton pattern.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s