design-patterns - with - when to choose singleton over static class?

Difference between static class and singleton pattern? (20)

What real (i.e. practical) difference exists between a static class and a singleton pattern?

Both can be invoked without instantiation, both provide only one "Instance" and neither of them is thread-safe. Is there any other difference?

  1. We can create the object of singleton class and pass it to method.

  2. Singleton class doesn't any restriction of inheritance.

  3. We can't dispose the objects of a static class but can singleton class.

  1. Lazy Loading
  2. Support of interfaces, so that separate implementation can be provided
  3. Ability to return derived type (as a combination of lazyloading and interface implementation)

static classes should not do anything need state, it is useful for putting bunch of functions together i.e Math (or Utils in projects). So the class name just give us a clue where we can find the functions and there's nothing more.

Singleton is my favorite pattern and use it to manage something at a single point. It's more flexible than static classes and can maintain state. It can implement interfaces, inherit from other classes and allow inheritance.

My rule for choosing between static and singleton:

If there are bunch of functions should be kept together, then static is the choice. Anything else which needs single access to some resources, could be implemented singleton.

Static Class:-

  1. You cannot create the instance of static class.

  2. Loaded automatically by the .NET Framework common language runtime (CLR) when the program or namespace containing the class is loaded.

  3. Static Class cannot have constructor.

  4. We cannot pass the static class to method.

  5. We cannot inherit Static class to another Static class in C#.

  6. A class having all static methods.

  7. Better performance (static methods are bonded on compile time)


  1. You can create one instance of the object and reuse it.

  2. Singleton instance is created for the first time when the user requested.

  3. Singleton class can have constructor.

  4. You can create the object of singleton class and pass it to method.

  5. Singleton class does not say any restriction of Inheritance.

  6. We can dispose the objects of a singleton class but not of static class.

  7. Methods can be overridden.

  8. Can be lazy loaded when need (static classes are always loaded).

  9. We can implement interface(static class can not implement interface).

Another advantage of a singleton is that it can easily be serialized, which may be necessary if you need to save its state to disc, or send it somewhere remotely.

As I understand the difference between a Static class and non-Static Singleton class, the static is simply a non-instantiated "type" in C#, where the Singleton is a true "object". In other words, all the static members in a static class are assigned to the type but in the Singleton are housed under the object. But keep in mind, a static class still behaves like a reference type as its not a value type like a Struct.

That means when you create a Singleton, because the class itself isnt static but its member is, the advantage is the static member inside the Singleton that refers to itself is connected to an actual "object" rather than a hollow "type" of itself. That sort of clarifies now the difference between a Static and a Non-Static Singleton beyond its other features and memory usage, which is confusing for me.

Both use static members which are single copies of a member, but the Singleton wraps the referenced member around a true instantiated "object" who's address exists in addition to its static member. That object itself has properties wherein in can be passed around and referenced, adding value. The Static class is just a type so it doesn't exist except to point to its static members. That concept sort of cemented the purpose of the Singleton vs Static Class beyond the inheritance and other issues.

Here's a good article:

Static classes

  • a class having all static methods.
  • better performance (static methods are bonded on compile time)
  • can't override methods, but can use method hiding. (What is method hiding in Java? Even the JavaDoc explanation is confusing)

    public class Animal {
        public static void foo() {
    public class Cat extends Animal {
        public static void foo() {  // hides


In summary, I would only use static classes for holding util methods, and using Singleton for everything else.


I read the following and think it makes sense too:

Taking Care of Business

Remember, one of the most important OO rules is that an object is responsible for itself. This means that issues regarding the life cycle of a class should be handled in the class, not delegated to language constructs like static, and so on.

from the book Objected-Oriented Thought Process 4th Ed.

I'm not a great OO theorist, but from what I know, I think the only OO feature that static classes lack compared to Singletons is polymorphism. But if you don't need it, with a static class you can of course have inheritance ( not sure about interface implementation ) and data and function encapsulation.

The comment of Morendil, "The design style embodied in a static class is purely procedural" I may be wrong, but I disagree. In static methods you can access static members, which would be exactly the same as singleton methods accessing their single instance members.

I'm actually thinking now that another difference is that a Static class is instantiated at program start* and lives throughout the whole life span of the program, while a singleton is explicitly instantiated at some point and can be destroyed also.

* or it may be instantiated at first use, depending on the language, I think.

In an article I wrote I have described my point of view about why the singleton is much better than a static class:

  1. Static class is not actually canonical class – it’s a namespace with functions and variables
  2. Using static class is not a good practice because of breaking object-oriented programming principles
  3. Static class cannot be passed as a parameter for other
  4. Static class is not suitable for “lazy” initialization
  5. Initialization and using of static class is always hard tracked
  6. Implementing thread management is hard

In singleton pattern you can create the singleton as an instance of a derived type, you can't do that with a static class.

Quick Example:

if( useD3D )
    IRenderer::instance = new D3DRenderer
    IRenderer::instance = new OpenGLRenderer

Main differences are:

  • Singleton has an instance/object while static class is a bunch of static methods
  • Singleton can be extended e.g. through an interface while static class can't be.
  • Singleton can be inherited which supports open/close principles in SOLID principles on the other hand static class can't be inherited and we need to make changes in itself.
  • Singleton object can be passed to methods while static class as it does not have instance can't be passed as parameters

Singleton is better approach from testing perspective. Unlike static classes , singleton could implement interfaces and you can use mock instance and inject them.

In the example below I will illustrate this. Suppose you have a method isGoodPrice() which uses a method getPrice() and you implement getPrice() as a method in a singleton.

singleton that’s provide getPrice functionality:

public class SupportedVersionSingelton {

    private static ICalculator instance = null;

    private SupportedVersionSingelton(){


    public static ICalculator getInstance(){
        if(instance == null){
            instance = new SupportedVersionSingelton();

        return instance;

    public int getPrice() {
        // calculate price logic here
        return 0;

Use of getPrice:

public class Advisor {

    public boolean isGoodDeal(){

        boolean isGoodDeal = false;
        ICalculator supportedVersion = SupportedVersionSingelton.getInstance();
        int price = supportedVersion.getPrice();

        // logic to determine if price is a good deal.
        if(price < 5){
            isGoodDeal = true;

        return isGoodDeal;

In case you would like to test the method isGoodPrice , with mocking the getPrice() method you could do it by:
Make your singleton implement an interface and inject it. 

  public interface ICalculator {
        int getPrice();

Final Singleton implementation:

public class SupportedVersionSingelton implements ICalculator {

    private static ICalculator instance = null;

    private SupportedVersionSingelton(){


    public static ICalculator getInstance(){
        if(instance == null){
            instance = new SupportedVersionSingelton();

        return instance;

    public int getPrice() {
        return 0;

    // for testing purpose
    public static void setInstance(ICalculator mockObject){
        if(instance != null ){
instance = mockObject;

test class:

public class TestCalculation {

    class SupportedVersionDouble implements ICalculator{
        public int getPrice() { 
            return 1;
    public void setUp() throws Exception {
        ICalculator supportedVersionDouble = new SupportedVersionDouble();


    public void test() {
          Advisor advidor = new Advisor();
          boolean isGoodDeal = advidor.isGoodDeal();
          Assert.assertEquals(isGoodDeal, true);



In case we take the alternative of using static method for implementing getPrice() , it was difficult to the mock getPrice(). You could mock static with power mock, yet not all product could use it.

Singleton's are instantiated, it's just there's only one instance ever instantiated, hence the single in Singleton.

A static class can't be instantiated by anything other than itself.

The true answer is by Jon Skeet, on another forum here.

A singleton allows access to a single created instance - that instance (or rather, a reference to that instance) can be passed as a parameter to other methods, and treated as a normal object.

A static class allows only static methods.

There is a huge difference between a single static class instance (that is, a single instance of a class, which happens to be a static or global variable) and a single static pointer to an instance of the class on the heap:

When your application exits, the destructor of the static class instance will be called. That means if you used that static instance as a singleton, your singleton ceased working properly. If there is still code running that uses that singleton, for example in a different thread, that code is likely to crash.

To illustrate Jon's point what's shown below cannot be done if Logger was a static class.The class SomeClass expects an instance of ILogger implementation to be passed into its constructor.

Singleton class is important for dependency injection to be possible.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ConsoleApplication2
    class Program
        static void Main(string[] args)

            var someClass = new SomeClass(Logger.GetLogger());


    public class SomeClass 
        public SomeClass(ILogger MyLogger)


    public class Logger : ILogger
        private static Logger _logger;
        private Logger() { }

        public static Logger GetLogger()
            if (_logger==null)
                _logger = new Logger();

            return _logger;

        public void Log()



    public interface ILogger
         void Log();

We have our DB framework that makes connections to Back end.To Avoid Dirty reads across Multiple users we have used singleton pattern to ensure we have single instance available at any point of time.

In c# a static class cannot implement an interface. When a single instance class needs to implement an interface for a business contracts or IoC purposes, this is where I use the Singleton pattern without a static class

Singleton provides a way to maintain state in stateless scenarios

Hope that helps you..

What makes you say that either a singleton or a static method isn't thread-safe? Usually both should be implemented to be thread-safe.

The big difference between a singleton and a bunch of static methods is that singletons can implement interfaces (or derive from useful base classes, although that's less common, in my experience), so you can pass around the singleton as if it were "just another" implementation.

When I want class with full functionality, e.g. there are many methods and variables, I use singleton;

If I want class with only one or two methods in it, e.g. MailService class, which has only 1 method SendMail() I use static class and method.