Does making singleton class sealed really help in achieving goal of singleton pattern C# - Static Initialization (A thread safe solution)

Question

I know other threads exist regarding this question but I couldn't find satisfactory answer for this. Why singleton class needs to be sealed in C# ? (To clarify my question)Does making it sealed really help it achieving goal of singleton (only one instance) ?

I have added more clarification about what I am wanting to know and trying to find reason for, hope readers understand what I am trying to discuss.

I am talking about MSDN article's thread safe solution : https://msdn.microsoft.com/en-us/library/ff650316.aspx.

In this article first they give solution which is not thread safe, then they give another solution using static initialization to make it thread safe and in that solution they make class: sealed

As per MSDN's explanation -- The class is marked sealed to prevent derivation, which could add instances. For a discussion of the pros and cons of marking a class sealed, see [Sells03].

When I tried to figure why they used Sealed in static initialization approach, only thing I could figure is: as they wanted to prevent additional instantiation they made it sealed (this only prevents instantiation done through derivation, nested sub class derivation could create additional instances but by using Sealed it doesn't prevent nested class from creating additional instances.) to achieve goal of singleton. If using sealed doesn't prevent additional instantiation through other ways then why use it ?

Below is the MSDN's thread safe solution:

public sealed class Singleton { private static readonly Singleton instance = new Singleton();

private Singleton(){}

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

My question is does MSDN's thread safe solution achieve goal of singleton by making it sealed? They made class sealed to prevent instantiation through derivation but that doesn't stop instantiation done through other ways. See my example below:

     public sealed class Singleton
     {
      private static readonly Singleton instance = new Singleton();

      private Singleton() { }

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

      public class nestedSingleton
      {
        public nestedSingleton()
        {
            Singleton moreThanOneObject = new Singleton();
        }
      }
    }

Answer 1

Simply put: if anyone can derive from it, there can be multiple instances. So you definitely need some way of preventing arbitrary derivation.

Now you can simply rely on a private constructor to prevent subclassing instead (and you need the private constructor anyway), but the only reason for making a Singleton class unsealed would be if you wanted a nested type to be the implementation, e.g.

public class Singleton
{
    public static Singleton Instance { get; }
        = (DateTime.Now.Seconds & 1) == 0
          ? (Singleton) new EvenSingleton() : new OddSingleton();

    private Singleton() {}

    private class OddSingleton : Singleton {}
    private class EvenSingleton : Singleton {}
}

This is properly a singleton - but it's a pretty unusual situation. It's vastly more common not to need a nested type to be the implementation, at which point it's clearer IMO to seal the singleton to make it clearer that you don't intend there to be any subclasses.

Basically it's communication as much as anything - a sealed class clearly prohibits derivation, whereas just having the private constructor (but no nested types) makes it more implicit. I think being explicit is clearer.

(Also, in earlier versions of C#, there are some bizarre ways you can get subclasses to compile with mutually recursive constructor calls so you never end up with a base constructor initializer. This has now been fixed, fortunately.)

To respond to a question addition:

Sealed keyword doesnt even make sense in this case if MSDN added it to prevent creating more instances of singleton by Nested sub classes.

In the example you've given, the nested class isn't a subclass. It looks like this:

public class nestedSingleton

whereas a nested subclass would look like this:

public class nestedSingleton : Singleton

(except ideally following .NET naming conventions).

Answer 2

It does not have to be

Implementing Singleton in C#

This is not safe on multithreads but a singleton

public class Singleton
{
   private static Singleton instance;

   private Singleton() {}

   public static Singleton Instance
   {
      get 
      {
         if (instance == null)
         {
            instance = new Singleton();
         }
         return instance;
      }
   }
}

Making it sealed would make it not possible to inherit it (eliminating a possible cause for several instances of a singleton)

Answer 3

The reason is very tied to implementation details.

For example, see the following simple and wrong singleton implementation in C#:

public class A 
{
     private static readonly A _instance;

     static A() 
     {
         _instance = new A();
     }

     public static A Instance => _instance;

     public string Name { get; set; }
}

Now let's derive it into B:

public class B : A 
{
    public string Surname { get; set; }
}

What would happen if you call B.Current static property?

// ERROR! Surname isn't a property of A
string surname = B.Instance.Surname; 

One of main drawbacks of not sealing a singleton class is that static members are still accessible on derived classes. That is, it's very confusing that you can access Instance property on B but it returns the singleton instance of A.

You can't take this risk and one simple and yet powerful way of avoiding confusion is sealing A. Since A is a singleton implementation, you don't want to be inheritable, because derived classes can't expand the singleton.

If you're agree with the point of avoiding the described situation, a more convenient implementation of singleton could be:

// SEALED
public sealed class A 
{
     private static readonly A _instance;

     // Avoid that other code excepting A class members
     // can instantiate A
     private A() {}

     static A() 
     {
         _instance = new A();
     }

     public static A Instance => _instance;

     public string Name { get; set; }
}

About the criticism of using a static read-only field instead of lazy-loading the single instance...

I've also checked that some seem to be against my proposal of instantiating the single instance as part of static constructor or using a field initializer. I could also simplify the implementation as follows:

public sealed class A 
{
     private A() {}

     private static readonly A _instance = new A();

     public static A Instance => _instance;
     public string Name { get; set; }
}

And, as far as I know, it provides more advantages than instantiating the single A instance in the Instance static property getter:

...

private static A _instance;

public static A Instance
{
    get
    {
         if(_instance == null) _instance = new A();

         return _instance;
    }
}

See this other Q&A to understand that static constructors are thread-safe: Is the C# static constructor thread safe?

In response to my answer's criticism about my sample singleton implementation

In some comment, Jon Skeet has said:

A singleton doesn't just provide a single instance - it ensure that it's the only instance ever created. See en.wikipedia.org/wiki/Singleton_pattern "In software engineering, the singleton pattern is a design pattern that restricts the instantiation of a class to one object." Your code doesn't do that.

It's not a good argument to invalidate my sample implementation. For example, most inversion of control containers let you configure the life-cycle to singleton of a given component and its implementation.

The whole implementation is a regular public class with no constraint preventing you from even configuring the same implementation for other component, or you can even instantiate the implementation with new (i.e. new A()) wherever you want.

But the so-called component is a singleton, because you've configured that it will be a single instance of the whole component across the entire AppDomain.

Now let's see the Implementation section on Singleton pattern (Wikipedia):

Implementation of a singleton pattern must satisfy the single instance and global access principles. It requires a mechanism to access the singleton class member without creating a class object and a mechanism to persist the value of class members among class objects. The singleton pattern is implemented by creating a class with a method that creates a new instance of the class if one does not exist. If an instance already exists, it simply returns a reference to that object. To make sure that the object cannot be instantiated any other way, the constructor is made private. Note the distinction between a simple static instance of a class and a singleton: although a singleton can be implemented as a static instance, it can also be lazily constructed, requiring no memory or resources until needed.

Comparing this implementation description with my sample implementation, I would say that the following implementation is a singleton:

public sealed class A 
{
     private A() {}

     private static readonly A _instance = new A();

     public static A Instance => _instance;
     public string Name { get; set; }
}

1. You can't publicly instantiate it.
2. It can be only a single instance within a given AppDomain.
3. It provides global access to itself.
4. It implements a method to create the single instance, but it's using C# specific syntax and syntactic sugar.
5. It's lazily instantiated when the static Instance property is first instantiated. This is how static constructors and static class field initializers work in C#.

Now let's analyze the inversion of control container case:

1. Usually components are defined by interfaces and abstract classes. Few times are concrete classes. Thus, you can't instantiate an abstract class or interface.
2. There's no Instance static property, but the implementation description on Wikipedia says: [...] It requires a mechanism to access the singleton class member without creating a class object and a mechanism to persist the value of class members among class objects. The fact that you can implement this with an Instance static property of singleton class is just an implementation detail on some programming languages. The pattern description is fine with how inversion of control containers work. Either something like service locator anti-pattern or just dependency injection, are mechanisms that provide the single instance.
3. With inversion of control containers you can access singletons globally. For example, Container.Resolve<ISomeComponentConfiguredAsSingleton>(). BTW, excepting on few cases, service locator is considered an anti-pattern.
4. Most inversion of control containers can provide custom factories where you can define how the component implementation will be instantiated.
5. Based on previous point, you can easily implement a factory with lazy-loading.

In summary, I would say that in my particular case I've already left my ortodoxy and I assume that design patterns are abstract definitions to implement solutions to common problems and most are and should be language-agnostic. As long as my code works as the description of a given design pattern for me is enough to consider I'm implementing the whole design pattern. You can even implement singleton without calling your class WhateverSingleton.