<< Design Patterns – Using the Strategy Pattern in C# | Design Patterns – Using the Adapter Pattern in C# >>

Design Patterns – Using the Singleton Pattern in C#

July 25, 2009 01:00 by author

Design Pattern articles in this series are listed below:

What is a Singleton Pattern?

Singleton Pattern belongs to the category of Creational Patterns. If you recall from the

Overview

article, the Creational Patterns are the subset of Design Patterns that encapsulate the logic of object creation. In a Singleton Pattern, there is a class (Singleton class) that ensures that only a single instance of itself can be created. It also provides a global point of access to this instance. So, irrespective of where in your code base this class is instantiated, you will always get access to the same instance.

Let’s consider a real world example to make this concept clear. Consider an application that generates different types of reports using different methods. The Reporting class also has a counter that maintains the number of reports generated irrespective of method is used. This is a perfect example of a Singleton Pattern (we will implement the code later). When one is faced with a business problem like this, it’s really tempting to simply create an instance of the reporting class as a static global variable. Though this works, this does not guarantee that the instance of the class is created only once. In the Singleton pattern, the responsibility of ensuring that there is a single instance of the class lies on the Singleton class and not on the client that consumes the Singleton.

How is it implemented?

Approach 1

Let’s take a look at the ReportingSingleton Singleton class

public class ReportingSingleton
{
    private static ReportingSingleton instance = new ReportingSingleton();
    public int NumReportsGenerated { get; set; }

    private ReportingSingleton() { }

    public static ReportingSingleton GetInstance()
    {
        return instance;
    }
}

The first thing you would note is that the constructor is private, so the client cannot instantiate this class directly. This is the main intent of the Creational patterns as they encapsulate the logic of object creation. So, how do you use this class? By using the snippet below.

ReportingSingleton singleton1 = ReportingSingleton.GetInstance();

As I noted earlier, our Reporting application has a counter that maintains the number of reports generated so far. This is done by the NumReportsGenerated property. Let’s take a look at the full client implementation

class Program
{
    static void Main(string[] args)
    {
        GenerateReportByMethodA();

        GenerateReportByMethodB();
    }

    private static void GenerateReportByMethodB()
    {
        ReportingSingleton singleton1 = ReportingSingleton.GetInstance();
        singleton1.NumReportsGenerated++;

        Console.WriteLine(String.Format("Number of reports generated so far : {0}", singleton1.NumReportsGenerated.ToString()));
    }

    private static void GenerateReportByMethodA()
    {
        ReportingSingleton singleton2 = ReportingSingleton.GetInstance();
        singleton2.NumReportsGenerated++;

        Console.WriteLine(String.Format("Number of reports generated so far : {0}", singleton2.NumReportsGenerated.ToString()));
    }
}

There are 2 different methods to generate reports. Each method instantiates the ReportingSingleton class and the class has the responsibility of ensuring there is always a single instance. When you run this program, you will get the following output.

Approach 2

The implementation in Approach 1 would be an issue in multithreaded environments. Consider a Reporting service that spawns multiple threads and each thread calls the GenerateReportByMethodA() or GenerateReportByMethodB(). The second approach uses lazy initialization – the class is not created until it is needed.

public class ReportingSingleton
 {
     private static ReportingSingleton instance = null;
     public int NumReportsGenerated { get; set; }

     private ReportingSingleton() { }

     public static ReportingSingleton GetInstance()
     {
         lock (typeof(ReportingSingleton))
         {
             if (instance == null)
             {
                 instance = new ReportingSingleton();
             }
             return instance;
         }
     }
 }

The difference between Approach 1 and Approach 2 is in the implementation of GetInstance() method. Note the use of the lock keyword. In multithreaded applications, there is a concept of a Critical Section. A Critical Section is a block of code that can be accessed only by 1 thread at any time. In C#, the critical section is implemented using the lock keyword. The thread that is accessing the critical section locks the code, executes the statements and unlocks so that other threads can access it.

Physical Model – Class Diagram

The class diagram is very simple. The GetInstance() method is the crux of this pattern.

Conclusion

The Singleton pattern is one of the simpler design patterns that involves only one class that is responsible to create only one instance of itself. If you enjoyed this article, check out other Design Pattern articles and do not forget to subscribe to the

RSS feed

Tags: design patterns
Categories: Design Patterns
Actions: E-mail | Kick it! | Permalink | comment

Comments (12) | RSS comment feed

Comment RSS

Design Patterns – An Overview Design Pattern articles in this series are listed below: Design Patterns - An Overview ...Design Patterns – Using the Observer Pattern in C# (Events and Delegates) Design Pattern articles in this series are listed below: Design Patterns - An Overview ...Design Patterns – Using the Abstract Factory Pattern in C# Design Pattern articles in this series are listed below: Design Patterns - An Overview ...

Comments

July 25. 2009 03:07

Assume that our Singleton class has a long running method and a state. What good is the lock for making the singleton class thread safe? In fact lock statement helps us making "getting the reference to singleton instanse" thread-safe; but not "using the singleton instanse". We need a mechanism of capture/release for that matter (implemented maybe by IDisposable mechanism and for sure a default timeout to prevent long waiting or dead locks). I have discussed this in other places too. Please take a look at this side too.

Kaveh Shahbazian

July 27. 2009 10:39

It's also worth looking at the MonoState pattern which has the same concept. Here is a good article from Robert C. Martin www.objectmentor.com/.../SingletonAndMonostate.pdf

Ivan Kotev

July 31. 2009 04:46

I think this solution is simpler:

private static readonly singletonObject = new SomeClass ();

Regards!

Juan C. Olivares

July 31. 2009 08:26

Oh... you could use the static constructor also...

Juan C. Olivares

July 31. 2009 11:04

Very nice article!

Stelios

July 31. 2009 12:06

Two questions:
1. is the first approach really not thread-safe?
2. can the instance field ever be null in GetInstance() method in second approach?

My answers:
1. it's thread safe
2. instance value in GetInstance() method can never be null in 2nd approach

Note:
The recommended solution if lazy instantation is not needed, is your first approach with the subtle change of making the instance field read-only (as already suggested in another comment).

Here is a good article about how to properly implement singletons in C#:
http://www.yoda.arachsys.com/csharp/singleton.html

Side-note:
Locking on typeof(public class) is discouraged, because it can introduce dead-locks.

Martin

July 31. 2009 12:18

Nice article. I would however issued the article with a warning. "Don't use this pattern unless you absolutely have to!" Singletons makes applications really hard to test and maintain. I tend to remove them when I find them in code or have the IoC container handle it for me. Just my 2 cents.

Jon Arild Tørresdal

July 31. 2009 20:11

#2 should not have:
private static ReportingSingleton instance = new ReportingSingleton();

it should have:
private static ReportingSingleton instance = null;

wierdling

July 31. 2009 20:50

@wierdling - You are correct. I have fixed this. Thanks

Admin

August 3. 2009 16:59

For example #1 you should have a static constructor even if it's going to be blank along with the private constructor

#  private static ReportingSingleton instance = new ReportingSingleton();
#     public int NumReportsGenerated { get; set; }
#
#     private ReportingSingleton() { }
#     static ReportingSingleton() { }

This will make sure the type is not marked with beforefieldinit by the compiler (src: www.yoda.arachsys.com/csharp/singleton.html)

@Jon, I agree the singleton pattern in this day and age is 98% bad practice, the only time recently I've used a singleton object was when wrapping an existing singleton object in C#/ASP.NET (.Cache class). A much better way to handle the singleton pattern is to use an IoC framework like StructureMap or Unity that lets you define the lifetime of the object to be singleton and have the IoC framework do all the lifting instead of your static class.

Chris Marisic

August 5. 2009 02:05