Why choose a static class over a singleton implementation?

Question

Static class is a technical tool in your box - basically a language feature.

Singleton is an architectural concept.

You may use a static class as a means to implement the singleton concept. Or you may use some other approach.

With static classes in C# there are two potential dangers if you're not careful.

• The requested resources will not be freed until the end of application life
• The values of static variables are shared within an application. Especially bad for ASP.NET applications, because these values will then be shared between all users of a site residing in a particular Application Domain.

From MSDN

Static classes and class members are used to create data and functions that can be accessed without creating an instance of the class. Static class members can be used to separate data and behavior that is independent of any object identity: the data and functions do not change regardless of what happens to the object. Static classes can be used when there is no data or behavior in the class that depends on object identity.

A key point is that static classes do not require an instance reference. Also note that static classes are specifically enabled by the language and compiler.

Singleton classes are just user coded classes implementing the Singleton design pattern. Singleton purpose is to restrict instantiation of an class to a single instance.

If you coded every static class as a singleton you'd have to instantiate the class every time you used it.

i.e.

Console.WriteLine('Hello World');

would become

Console c = Console.getInstance();
c.WriteLine('Hello World');

I'd say they're both (generally) poor solutions. There are a few use cases for static classes, primarily simple utility ones (Extension Methods in C# 3.0 come to mind). With any degree of complexity, though, testability issues start cropping up.

Say class A depends on static class B. You want to test class A in isolation. That's hard.

So you go with a Singleton. You have the same problem - class A depends on singleton B. You can't test class A in isolation.

When class B has other dependencies (such as hitting a database) or is mutable (other classes can change its global state), the problem is exacerbated.

IoC (Inversion of Control) container libraries are one solution to this problem; they let you define Plain Old Classes as having a long lifespan. When combined with a mocking library, they can make your code very testable.

Static classes are much easier to implement - I have seen many attempts at thread-safe singletons in C# that employs naive locking schemes instead of depending on the run-time's guaranteed one-time initialization of static fields (optionally inside a nested class to delay instantiation).

Other than that, I think singletons are great if you need to pass around a reference to an object that implements a specific interface, when that 'implemention' should be singleton, something which you cannot do with static classes.

One consideration I don't see mentioned is that preferring a solution using an instance of a class (singletons, or their DI equivalent) allows you to provide a class on which other users of your code may define extension methods -- since extension methods only work with non-static classes as the this parameter. In other words, if you have a line like:

GlobalSettings.SomeMethod();

Then syntactically the only thing that can be accessed via GlobalSettings are members you provide. In contrast, if GlobalSettings is an instance (singleton or otherwise) then consumers may add their own extensions to GlobalSettings that they would be unable to do otherwise:

application.GlobalSettings.CustomSomethingOrOther();

or

GlobalSettings.Instance.CustomSomethingOrOther();