INTRODUCTION: Singleton is the design pattern that is the easiest to abuse and hardest to nail down. You must correctly ascertain when they are appropriate and to what scope. But first, what is a Singleton? Singletons are classes that should only be instantiated once per application. These classes typically represent a set of functionality that is global to the application, yet deserves to be encapsulated into a single set of functionality.

The Singleton should expose itself as a static property from the class definition, making available public instance methods only from the referenced static property. Singletons should have a single purpose. Some examples are a Window manager for an Application, or a Report generator. I’ve even used a Singleton to manage the state of a WinForms ribbon. The main thing to remember is that the Singleton only gets instantiated at a global scope and should have a narrow focus.

For an example, let’s make a Singleton that performs acts as a state manager for a fictional application. This application will represent a wizard that must move between three steps.

EXAMPLE:

public class AppSingleton
{
  // Private static reference to the long instance of this
  // Singleton.  
  private static readonly AppSingleton _instance = new AppSingleton();

  // Current state of the application.
  private State _state = State.Start;

  public State State => _state;

  // Private constructor ensures that only the Singleton
  // can create new instances.
  private AppSingleton() { }

  public AppSingleton Instance => _instance;

  // Instance method to change the state of the application,
  // returns the resulting app state.
  public State MoveNext()
  { 
    switch(_state)
    {
      case State.Start:
        _state = Middle;
        break;

      case State.Middle:
        _state = Finish;
        break;

      case State.Finish:
        _state = Completed;
        break;
    }
    return _state;
  }

  // Instance method to change the state of the application,
  // returns the resulting app state;
  public State MovePrevious()
  {
    switch(_state)
    {
      case State.Middle:
        _state = First;
        break;

      case State.Finish:
        _state = Middle;
        break;
    }
  }

  // Here we can tell the singleton to perform some work.
  // You do not need this method signature, you can have
  // as many "worker" methods as is necessary.  This is 
  // just an example!
  public void DoSomething(params object[] args)
  {
    // DO some work!
  }
}

public enum State
{
  Start, Middle, Finish, Completed
}

public class Program
{
  public static void Main(string[] args)
  {
    AppSingleton.Instance.DoSomething(1);
    var state = AppSingleton.Instance.MoveNext();

    if(state != State.Start) 
    {
      // We moved state!  Do something else!
      AppSingleton.Instance.DoSomething(2);

      // Let's go back and try again!
      state = AppSingleton.Instance.MovePrevious();

      // Etc.
    }
    else
    {
      // Uh-oh, the singleton says it cannot move.
    }
  }
}

Here our application state is managed by the AppSingleton. The main program simply attempts to manipulate that state by providing data to the Singleton to process. In a real app, there would be user interaction that would drive the wizard forwards and backwards.

CONCLUSION: Singletons are a very powerful arrow in your C# quiver. Single-user applications are great usages for them. If you are not sure if you should use a singleton, ask yourself these questions:

  • Does the Singleton represent a single state within the application?
  • Does the Singleton have logic that should be encapsulated?
  • Do you need to control the object lifecycle for the Singleton?

If your answer is yes to these questions, a Singleton is right for you!