Singleton design pattern vs static class

Question

What are the scenarios when Singleton design pattern is preferred over static class & when static class is preferred over Singleton design pattern?

The preferred way is not to use neither singletons nor static classes. — empi, Mar 02 '13 at 19:57
the pattern is discussed [here](http://jalf.dk/blog/2010/03/singletons-solving-problems-you-didnt-know-you-never-had-since-1995/) and [here](http://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons) and [here](http://stackoverflow.com/questions/1008019/c-singleton-design-pattern) and [here](http://stackoverflow.com/questions/1020312/are-singletons-really-that-bad) and [here](http://blogs.msdn.com/b/scottdensmore/archive/2004/05/25/140827.aspx) and [here](http://programmers.stackexchange.com/questions/40373/so-singletons-are-bad-then-what) — default, Mar 02 '13 at 20:10
@Default: Singletons I get. What's so bad about (propertly used) static classes. They are required for extension methods which I use frequently. — Pieter Geerkens, Mar 02 '13 at 20:13
@PieterGeerkens, depends on whether they are "static". It's often better to construct an implementation of an interface, even if it has no state, that way you can inject it. — Tony Hopkinson, Mar 02 '13 at 20:33
@Tony: Extension methods can ONLY be defined in non-generic static classes. I routinely add "public static partial class Extensions { ... }" at the end of my class files with a method or two that are utility for the preceding class, but most conveniently defined as static methods for some other class. — Pieter Geerkens, Mar 02 '13 at 20:37
Yes I know. But that's not an issue. You'd be injecting an instance that had an extension, not the extension itself. — Tony Hopkinson, Mar 02 '13 at 20:47
@Tony: Aren't you making an assumption that the OP's very general question is looking at specific "bad practice" scenarios, rather than just being the gneral question that it is: "What's good and bad about these two possible choices" — Pieter Geerkens, Mar 02 '13 at 22:15
[Jon's article](http://csharpindepth.com/Articles/General/Singleton.aspx) (although slightly different) covers some part of it. — publicgk, Mar 02 '13 at 22:31
Bad practice? There's more than a few Singletons and static classes in my code. They were good solutions to my difficulties at the time, just wish someone had told me they were going to make DI harder. If you aren't or can't use DI, then it's a moot point — Tony Hopkinson, Mar 03 '13 at 12:33
Possible duplicate of [Difference between static class and singleton pattern?](https://stackoverflow.com/questions/519520/difference-between-static-class-and-singleton-pattern) — CoolOppo, Dec 18 '18 at 11:38

score 8 · Accepted Answer · answered Mar 02 '13 at 20:25

8

This is not really an either or scenario.

Singletons are instances with a static getter, and a private constructor. They are not static classes.

Singleton with certain provisos is a way of ensuring you only have one instance of class.

So the first question is. Do you need an instance, i.e. does this thing have a state, the second question is given how difficult they make unit testing, do you want one at all.

Have a look at the Service Locator pattern, for instance.

answered Mar 02 '13 at 20:25

Tony Hopkinson

20,172
3
31
39

Static classes can have state. – jmoreno Oct 29 '17 at 15:35
Aye, I was alluding to state specific to the instance. – Tony Hopkinson Nov 01 '17 at 14:00

Dzienny · Answer 2 · 2013-03-02T21:15:41.137

8

Generally singletons are superior to static classes.

Singleton in contrary to static class:

can inherit, and can be inherited;
can implement interface;
can be serialized;
can be passed to other classes;
can be disposed.

If you choose static class then you choose concrete, there's no flexibility. However, if you use singleton you have to remember to make the instantiation of it thread safe.

edited Mar 02 '13 at 21:15

answered Mar 02 '13 at 20:50

Dzienny

3,295
1
20
30

Aren't you swimming against a very large and influential crowd? Care to expand a bit more on your reasoning? – Pieter Geerkens Mar 02 '13 at 22:16
1

Nah all his points are right. They both can hamper DI, often badly – Tony Hopkinson Mar 03 '13 at 12:28
I think this point of view is obsolete and you did not explain how any of your 5 bullet points can be seen as a good thing. Static classes are performant, don't need instantiation and are easy to unit test – teikitel Dec 04 '19 at 10:36

score 3 · Answer 3 · answered Mar 02 '13 at 20:00

3

If you're only using a class as a container for some functions, use a static class.. but in most other cases, you're best off using the Singleton design pattern, because you'll probably want to reuse that object or instantiate it as a non-singleton.

answered Mar 02 '13 at 20:00

Henry van Megen

2,159
2
23
35

If I am not wrong then static class will be loaded into the memory once application gets started and remains there till application runs. While Singleton class is loaded into memory when its 1st instance is created & remains there when application is closed. So, can you please suggest some scenarios to justify once preference over other? – WpfBee Mar 02 '13 at 20:10
A good scenario where one would use a singleton is where you'd want just ONE instance of a class to (for example) prevent file-locks when building a logging class (something that locks a file on the filesystem and can only do this once)... other than that I would have to agree with the [comment](http://stackoverflow.com/a/15179303/286238) @Dzienny stated below. – Henry van Megen Mar 04 '13 at 15:57

score 2 · Answer 4 · answered Mar 02 '13 at 20:03

Static class are specialty difficult to test. And you can't use the constructor for anything useful.

static classes are preferred in helper methods like the MVC helper.

You can see here tome limitations of a static class. They can only have static members and are sealed.

score 1 · Answer 5 · answered Mar 06 '13 at 16:51

My final take from this discussion: 1. An object has some state. State means current values of object's attributes. So, if you want to have a scenario, where you want to have some state that can be changed and also want to have only one instance, then use Singleton class. e.g. suppose there is a log file that you want to update after some successful operation or on some exception. To update this log file we must have a lock on it to avoid any inconsistent data, and it can be achieved through Singleton class. 2. When you do not require state of your object and want to load your class into the memory when application gets started & be remain there till life of application - use Static class.

That's pretty much it. Though load in to memory when app started (almost) is more of a consequence of it being static. Instantiate a singleton in Main would give you that as well. Do bear in mind the comments about DI even if it's only in respect to unit testing though. Singleton or static could hurt you there more than it helps elsewhere. Depends on how mad you go with them. — Tony Hopkinson, Mar 06 '13 at 17:40

score 0 · Answer 6 · answered Mar 02 '13 at 20:12

You can use a static class to offer you simple methods that do not require any state and when you do not need to instatiate an object.

Using a singleton means that you only want to instatiate an object once and you can pass it around and alter its state. With singletons you can also have inheritance or implement an interface.

score 0 · Answer 7 · answered Oct 29 '17 at 16:07

The main difference between the two is that a singleton can implement an interface, and that allows changing it's behavior for either testing or runtime reasons. A static class is static, and while it can have state, drastically changing it's behavior is going to be difficult.

A singleton, being an instance of a class, can implement an interface, and if used with methods that expect that interface, can easily be be replaced with different behavior.

Logging is a common usage for both.

A static logger is unlikely to be able to log to different medium (database, xlm file, text file, json, stream, webservice), because you either have to use a different API for the calls, or set some state and then have all of the methods impelement all of the different kinds of of persistence.

A singleton logger can implement ILog, and then if you need to switch from logging to a database to logging to a web service, you just use another class (which might or might not be a singleton).

A singleton can be used to move away from a static class slowly. A static class can replace a singleton when you realize that you are never going to be changing behavior.

Neither are hard to test in themselves. But it can be a problem to test other classes that use them. Particularly, a static class -- it is not unknown to want slightly different behavior in some respect (say logging, or having the source/destination of files be a file share vs sharepoint) when testing vs production. In that case, having the class be a singleton allows more easily changing that behavior.

Singleton design pattern vs static class

7 Answers7