Sealed class, with private constructor, versus Static class

Question

When "studying" this class, I checked that it is sealed and has the private builder:

public sealed class Interaction
{
    /// <remarks>
    /// CA1053: Static holder types should not have public constructors
    /// </remarks>
    private Interaction()
    {

    }

    //Vários métodos estáticos públicos e privados
    ...
    ...
}

Declare it static and "remove" the constructor

public static class Interaction
{

    //Vários métodos estáticos públicos e privados
    ...
    ...
}

changes in some aspect how it can be used/consumed?

Answer 1

The main difference is that the static class cannot even be instantiated. A normal class with private constructor just doesn’t let any code out of the class instantiate it, but it can be instantiated internally, after all its static methods can access this constructor.

This works:

using static System.Console;
                    
public class Program {
    public static void Main() {
        var instancia = Instancia.Factory();
        WriteLine(instancia.GetType());
    }
}

public class Instancia {
    private Instancia() {}
    public static Instancia Factory() => new Instancia();
}

Behold working in the ideone. And in the .NET Fiddle. Also I put on Github for future reference.

This internal instance can be only internally or can be made available externally to anyone who wants to use, so it depends on how it was coded.

It is even possible to call this private builder publicly in less orthodox ways, with reflection, for example.

Another difference is that the normal class can have non-static members. And it can even make sense knowing that it can be instantiated.

Just remember that if there is a static constructor in any of the classes, it will be called sometime before its use. The normal constructor of the class will only be called by code. It is possible until a static constructor of the normal class is used to create an internal instance.

A technical detail is that static classes are at the same time sealed and abstract, can check this in CIL.

Why prefer static class where it makes sense

If the people involved in the code don’t have to do something crazy, the normal class with private constructor may function as the static class, but it depends on following the convention. It would be much better to ensure this via code. And let’s face it, if you say it is static, it sends the right message of what your intention is.

I believe that people use this technique here and there because C# 1 had no static class, just like Java. There’s no point doing this anymore, unless you have a good reason or want to use some trick that can justify existence.

This "trick" is often used to create the Singleton.