Design Patterns - A deep dive 3

Welcome to a series of articles on design patterns.

In the previous articles, we have covered the following areas:

Part 1 - looks at design patterns at a high level to understand what they can/can't do.

Part 2 - looks at the basic categorization of the patterns & a one-line definition of each pattern under that category.

The previous two parts have been a very high level overview of design patterns. The articles henceforth will concentrate on a single pattern & hopes to provide an insight regarding coding the pattern, uses of that pattern & some common gotcha's while using that pattern.

This article (Part 3) looks at one of the simplest and most commonly used type of Creational Design Pattern called as the Singleton Design Pattern.

What is a Singleton Pattern?

An instance of a class is considered Singleton if it meets the following criteria:

1. There is only one instance of the class during the lifetime of that application
2. Any attempt to instantiate another instance of this class would return the previously created instance
3. The constructor of this class is either private or protected only.

Why is Singleton Pattern classified as a Creational Pattern?

Creation design patterns are a category of design patterns in which there is some special process in the "creation" of an instance of a class.

In case of Singleton pattern, the constructor of the class is not accessible & so an instance of that class cannot be created. The class will internally create an instance of itself & return a handle to this instance each time.

Due to this special behavior of the constructor, this pattern is classified as a Creational Pattern.

Lets talk code

public class Singleton{
    private static Singleton m_INSTANCE = null;
    private Singleton(){}
    public static Singleton GetInstance(){
        if(m_INSTANCE == null)
            m_INSTANCE = new Singleton();
        return m_INSTANCE;
    }
}

The interesting features of this class are: the constructor, the method GetInstance() and the private static Singleton type field m_INSTANCE, which we will get into more deeply in the following sections.

The constructor

The constructor of the Singleton class has been declared private. You could also declare it protected. Any other modifier like public or internal would allow a possibility to create an instance of this class & would defeat the purpose of a Singleton.

private Singleton(){}

The main concept to understand here is that we are restricting creating the instance of this class by setting the access modifier to the constructor. So, now no consumer of the class can create an instance of it. The only way we can get get an instance is to call the GetInstance() method & use that instance.

The field m_INSTANCE

The field m_INSTANCE is a private static field which will hold the object of the Singleton class.

private static Singleton m_INSTANCE = null;

Since this field is lazy-initialized & the GetInstance() method always returns this object, we have been able to control the creation of instances for the Singleton class.

The GetInstance() method

The GetInstance() method is the only way we would be able to get an instance of the Singleton class.

public static Singleton GetInstance(){
    if(m_INSTANCE == null)
        m_INSTANCE = new Singleton();
    return m_INSTANCE;
}

In the class shown above, we note that we are lazy-initializing the private static Singleton type field m_INSTANCE. This code ensures that there would be only one instance of the type which will be created the first time GetInstance() method is called. For any other call after this, the object stored in m_INSTANCE will be returned without creating a new instance.

The point to note about the GetInstance() method is that it has been declared public static with a return type of Singleton. As mentioned previously, since the constructor is private/protected, we will not be able to create an instance of the class & so we will need this static method to get the instance.

Uses of Singleton Pattern

The Singleton pattern is extremely simple to implement & use. Typically, items which need to be initialized only once during the application life implement this pattern. Some of the common examples of such items can be: User Preferences & Settings, Thread/Connection pools, context objects, handle to Application Services (logging, data access, error handling etc.)

In short: "Singletons are most appropriate for services that donot change change their nature based on their invocation context" (c2.com, 2008)

The Bells & Whistles

In this section, we will look at some interesting items which need to be kept in mind while using the Singleton Pattern which might actually make it evil:

1. Singleton's v/s Global Variables - IMHO while Singleton's are a classes where we are restricting creating mutiple instances, global variables are more like "declared instances". Given this mindset, I would expect a Global Variable to be changed during the lifetime of an application based on certain conditions in the application, while a Singleton would remain in the same state. One more difference I note is that Global Variables are truly global to the application, but a Singleton could be accessible to a part of the application/thread.
2. Singleton's & performance - One of the most important decisions while using a Singleton is when do we actually instantiate the members of the class & how expensive is it to keep this instance in memory? In the code sample shown previously, we had lazy initialized the m_INSTANCE member which was sufficient for that case. But given a more complex or expensive resource to create, we need to re-look at our design & check if it makes sense in having a Singleton or use some other mechanism.
3. Singleton's & state - One of the core concepts of Singleton is that it maintain its state as long as the application lasts. One of the drawbacks of this is that to load a different state (For example: running Unit Tests), we need to expose methods to set the new state, which quite defeats the idea that Singleton's retain their state. The other alternative is to reload the application with a different state for the Singleton instance, but then is this acceptable for a Unit Test?

Wrap up

In this article we have seen how a Singleton class can be created, what are its main elements. I would love to hear your thoughts, ideas & experiences using the Singleton Pattern.

In the next article, we will look at another Creational Design Pattern.