Singleton Pattern (Creational Pattern)

Singleton Pattern: It is a type of Creational Pattern. When we need to make sure that one (and only one) instance of a class is created, Singleton pattern comes into picture. If you think about- how we can make sure that only one instance of a class is created; you will come up with a blueprint of a class design. That blueprint will be very close to singleton pattern’s standard implementation.

It involves one (and only one) class which can instantiate itself, and no other class can create its instances. It also makes sure that there is an easy and global access to that instance.

publicclassExplorer
{
    privatestatic Explorer ExplorerInstance;
    privateExplorer (); //constructor
    publicstatic Explorer getInstance(); //global access to the instance
    stringgetStringValue();
    voidsetStringValue(string LStringValue);
}

The class Explorer can be instantiated by itself, and its instance can be accessed by other classes. The method getInstance() can be implemented as below:

publicstatic Explorer getInstance()
{
    if (ExplorerInstance == null)
        ExplorerInstance = new Exlporer();
    return ExplorerInstance;
}

Singleton patterns are useful when you don’t want to use global variables. As Developers we know using Global variables should be avoided. Global variables have several disadvantages such as initialization uncertainty, hindrance in code modularity and re-use. Singleton Pattern alleviates these problems. Let’s see what are the liabilities associated with Singleton pattern with an example.

//**  ExplorerA  **//
 
publicvoidgetExplorerString()
{
    if (Explorer.getInstance().getStringValue() != null)
    {
        //do something
    }
}

//***************************************************////**  ExplorerB  **//

 
publicvoidsetExplorerString()
{
    Explorer.getInstance().setStringValue(‘test’);
}

Two modules, ExplorerA and ExplorerB, are derived from the class Explorer. ExplorerA uses the (one and only instance) ExplorerInstance to setStringValue() for the instance. ExlporerB can access/modify those changes. Thus, ExplorerA and ExplorerB are closely coupled. Not only this approach caused a hindrance in code modularity, it also reduces the code re-use. The idea of single instance of Singleton Pattern causes a coupling among all modules/classes/objects using that instance. It does not provide a complete solution and thus should be used with caution.

One good place to use Singleton pattern is a 'Logging class' in you project, because it does not affect the execution of the actual code. With logging enabled or disabled, your project works the same. A logging class is used often in a project. 'Dependency Injection' may be another way to go about it, but imagine injecting the same dependency in almost every class in your project. Cumbersome.

How well does the object oriented Single Responsibility Principle go with this Pattern? Interesting Read: You are bringing me down Singleton!