When should you use the singleton pattern instead of a static class? [closed]

Answer 1

When the single class needs state. Singletons maintain a global state, static classes do not.

For instance, making a helper around a registry class: If you have changable hive (HKey Current User vs. HKEY Local Machine) you could go:

RegistryEditor editor = RegistryEditor.GetInstance();
editor.Hive = LocalMachine

Now any further calls to that singleton will operate on the Local Machine hive. Otherwise, using a static class, you would have to specify that Local Machine hive everytiem, or have a method like ReadSubkeyFromLocalMachine.

Answer 2

If a singleton is something you can dispose of, to clean up after it, you can consider it when it's a limited resource (ie. only 1 of it) that you don't need all the time, and have some kind of memory or resource cost when it is allocated.

The cleanup code looks more natural when you have a singleton, as opposed to a static class containing static state fields.

The code, however, will look kind of the same either way so if you have more specific reasons for asking, perhaps you should elaborate.

Answer 3

Singleton is like a service, as already mentioned. Pro is its flexibility. Static, well, you need some static parts in order to implement Singleton.

Singleton has code to take care of instantiation of th actual object, which can be a great help if you run into racing problems. In a static solution you may need to deal with racing problems at multiple code locations.

However, same as Singleton can be constructed with some static variables, you may be able to compare it with 'goto'. It can bevery useful for building other structures, but you really need to know how to use it and should not 'overuse' it. Therefore general recommendation is to stick to Singleton, and use static if you have to.

also check the other post: Why choose a static class over a singleton implementation?

Answer 4

• Singletons can implement interfaces and inherit from other classes.
• Singletons can be lazy loaded. Only when it is actually needed. That's very handy if the initialisation includes expensive resource loading or database connections.
• Singletons offer an actual object.
• Singletons can be extended into a factory. The object management behind the scenes is abstract so it's better maintainable and results in better code.

Answer 5

Singletons should not be used in the same way as static classes. In essense,

MyStaticClass.GetInstance().DoSomething();

is essentially the same as

MyStaticClass.DoSomething();

What you should actually be doing is treating the singleton as just another object. If a service requires an instance of the singleton type, then pass that instance in the constructor:

var svc = new MyComplexServce(MyStaticClass.GetInstance());

The service should not be aware that the object is a singleton, and should treat the object as just an object.

The object can certainly be implemented, as an implementation detail and as an aspect of overall configuration, as a singleton if that makes things easier. But the things that use the object should not have to know whether the object is a singleton or not.

Answer 6

refer this

summary:

a. One easy rule of thumb you can follow is if it doesn’t need to maintain state, you can use a Static class, otherwise you should use a Singleton.

b. use a Singleton is if it is a particularly “heavy” object. If your object is large and takes up a reasonable amount of memory, lot of n/w calls(connection pool) ..etc. To make sure that its not going to be instantiated multiple times. A Singleton class will help prevent such the case ever happening