Singleton Design Pattern with Real-Time Example in C#

The Singleton Pattern ensures that a class has only one instance in the across application and the object instance coordinates across the app.

This pattern is the simplest design pattern and is used to restrict the creation of multiple object instances.

This pattern is the simplest design pattern and is used to restrict the creation of multiple object instances.

A class should have the following structure for the Singleton Design Pattern:

1.      Should have a private or protected constructor. No public and parameterized constructors.

2.      Should have a static property to return an instance of a class.

3.      At least have one non-static public method for a singleton operation.

The Singleton pattern is often used for:

1.      Logging

2.      Database connections

3.      Caching

4.      Thread pools

5.      Data Sharing

The main purpose of the singleton design pattern is to ensure that a class only has one instance and provide a global point of access to it throughout the life of an application.

There are several ways to Implement the Singleton Pattern in C#

1.      Non-thread-safe version

2.      Simple thread safety via locking

3.      Double-checked locking

4.      Safety through initialization

5.      Safe and fully lazy static initialization

6.      Lazy<T>

Let's see the implementation of the Singleton Pattern in C# in depth –

Example 1 for Non-thread-safe version:

//First version - not thread-safe

//Bad code! Do not use it!

public sealed class Singleton

{

    private static Singleton instance=null;

    private Singleton() {   }

    public static Singleton Instance

    {

        get

        {

            if (instance==null)

            {

                instance = new Singleton();

            }

            return instance;

        }

    }

}

Example 2 for Simple thread safety via locking:

//Second version - simple thread-safety

public sealed class Singleton

{

    private static Singleton instance = null;

    private static readonly object padlock = new object();

    Singleton()  { }

    public static Singleton Instance

    {

        get

        {

            lock (padlock)

            {

                if (instance == null)

                {

                    instance = new Singleton();

                }

                return instance;

            }

        }

    }

}

Example 3 for Double-checked locking:

//Third version - attempted thread safety using double-check locking

// Bad code! Do not use it!

public sealed class Singleton

{

    private static Singleton instance = null;

    private static readonly object padlock = new object();

    Singleton() {  }

    public static Singleton Instance

    {

        get

        {

            if (instance == null)

            {

                lock (padlock)

                {

                    if (instance == null)

                    {

                        instance = new Singleton();

                    }

                }

            }

            return instance;

        }

    }

}

Example 4 for Safety through initialization:

//Fourth version - not quite as lazy, but thread-safe without using locks

public sealed class Singleton

{

    private static readonly Singleton instance = new Singleton();

    // Explicit static constructor to tell C# compiler

    // not to mark type as beforefieldinit

    static Singleton() {  }

    private Singleton() {  }

    public static Singleton Instance

    {

        get

        {

            return instance;

        }

    }

}

Example 5- Safe and fully lazy static initialization: 

//Fifth version - fully lazy instantiation

public sealed class Singleton

{

    private Singleton()  {  }

    public static Singleton Instance { get { return Nested.instance; } }       

    private class Nested

    {

        // Explicit static constructor to tell C# compiler

        // not to mark type as beforefieldinit

        static Nested()

        {

        }

        internal static readonly Singleton instance = new Singleton();

    }

}

Example 6 –  Lazy<T> :

If you are using .NET 4 (or higher), you should use the System.Lazy<T> type to make the laziness really simple.

//Sixth version - using .NET 4's Lazy<T> type

public sealed class Singleton

{

    private static readonly Lazy<Singleton> lazy =

        new Lazy<Singleton>(() => new Singleton());

   

    public static Singleton Instance { get { return lazy.Value; } }

    private Singleton() {  }

}

The Singleton pattern, like any design pattern, comes with its own set of advantages and disadvantages. Let's take a look:

Advantages of the Singleton Design Pattern:

Single Instance:  The most obvious advantage is that a Singleton ensures a class has only one instance, and it provides a global point of access to that instance.

 

Global Point of Access: Because the Singleton provides a single, globally accessible point of access to the instance, it's easy to use and avoids the need for passing instances around your code.

 

Lazy Initialization: The instance is created only when it's requested for the first time, which can be beneficial for performance. This is particularly true if the creation of the instance is resource-intensive.

 

Memory Efficiency: It helps in saving memory by having only one instance for the entire application, especially in scenarios where the object is large or consumes significant resources.

 

Disadvantages of the Singleton Design Pattern:

Global State: Because the Singleton pattern provides a global point of access, it introduces a global state to your application. This can make it harder to reason about the flow of data and can lead to unintended dependencies between classes.

 

Testing Difficulties: Singletons can be difficult to test because they introduce a global state. When testing a class that depends on a Singleton, it's challenging to isolate and control the environment.

 

Inflexibility: The singleton pattern creates a rigid structure in the application. If you later decide that you need multiple instances or want to change the instantiation logic, you might find it challenging to modify the Singleton implementation.

 

Thread Safety: The basic Singleton implementation is not thread-safe. If multiple threads try to access the instance simultaneously and it hasn't been created yet, it might result in the creation of multiple instances. Adding thread safety can make the code more complex.

 

Violates Single Responsibility Principle:

Sometimes, a Singleton class might take on responsibilities beyond managing its instance, violating the Single Responsibility Principle. For example, it might handle configuration settings, logging, and other concerns in addition to being a singleton.

When to Use:

When a Single Instance is Necessary:

Use a Singleton when you need to ensure that a class has exactly one instance and when that instance must be accessible from a global point of entry.

 

When Lazy Initialization is Preferred:

If the creation of the instance is resource-intensive and you want to defer it until it's actually needed, a Singleton can be a good choice.

 

When Global State is Acceptable:

If having a global state is acceptable for your application and doesn't introduce issues, a Singleton might be suitable.

In conclusion, the Singleton pattern can be a powerful tool, but it should be used judiciously. It's essential to weigh its advantages against its disadvantages and consider alternatives, especially in the context of modern software design principles and patterns.