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

Answer 1

Singleton pattern is generally used to service instance independent or static data where multiple threads can access data at same time. One example can be state codes.

Answer 2

If by "static class" you mean a class that has only static variables, then they actually can maintain state. My understanding is the that the only difference would be how you access this thing. For example:

MySingleton().getInstance().doSomething();

versus

MySingleton.doSomething();

The internals of MySingleton will obviously be different between them but, thread-safety issues aside, they will both perform the same with regards to the client code.

Answer 3

One of my favorite discussions about this issue is here (original site down, now linked to Internet Archive Wayback Machine.)

To summarize the flexibility advantages of a Singleton:

• a Singleton can be easily converted into a factory
• a Singleton can be easily modified to return different subclasses
• this can result in a more maintainable application

Answer 4

Static classes are instantiated at runtime. This could be time consuming. Singletons can be instantiated only when needed.

Answer 5

I'd argue the only difference is syntax: MySingleton.Current.Whatever() vs MySingleton.Whatever(). The state, as David mentioned, is ultimately "static" in either case.

---

EDIT: The bury brigade came over from digg ... anyhow, I thought of a case that would require a singleton. Static classes cannot inherit from a base class nor implement an interface (at least in .Net they cannot). So if you require this functionality then you must use a singleton.

Answer 6

A singleton may have a constructor and destructor. Depending on your language, the constructor may be called automatically the first time your singleton is used, or never if your singleton is not used at all. A static class would have no such automatic initialization.

Once a reference to a singleton object is obtained, it can be used just like any other object. The client code may not even need to know its using a singleton if a reference to the singleton is stored earlier on:

Foo foo = Foo.getInstance();
doSomeWork(foo); // doSomeWork wont even know Foo is a singleton

This obviously makes things easier when you choose to ditch the Singleton pattern in favor of a real pattern, like IoC.