Why use singleton instead of static class?

Question

When would a singleton actually be easier or better than a static class? It seems to me creating a singleton is just extra effort that\'s not actually needed, but I\'m sure

Answer 1

Even though IMHO the singleton pattern is a rather overused pattern, it does sometimes offer benefits, such as:

• The ability to use different kinds of objects (that inherit from the same base) as the instance (think data providers where one uses the filesystem and one an SQL database, for example)
• Serializability. I haven't used a framework that can automatically serialize static classes.
• Using less static fields. For some people this is more of an esthetic feature, but in some cases it has practical benefits.

Answer 2

Singletons preserve the conventional class approach, and don't require that you use the static keyword everywhere. They may be more demanding to implement at first, but will greatly simplify the architecture of your program. Unlike static classes, we can use singletons as parameters or objects.

Also,you can use singletons with interfaces just like any other class.

Answer 3

Singletons are often preferred to global variables because:

• They don't pollute the global namespace (or, in languages with namespaces, their containing namespace) with unnecessary variables.
• They permit lazy allocation and initialization, whereas global variables in many languages will always consume resources.

Source

EDIT:

One cool use of the singleton is, when combined with the factory method, can be used to create the Flyweight pattern. This is when you create a new object, the Factory (instead of creating a new object) first checks to see a singleton of that object is already made, if it is, it just returns that object, if not, it creates a new singleton and returns that, keeping track of the singletons it creates. Flyweights work because of the immutability of the singleton.

Answer 4

Singletons always seemed a bit redundant to me. I prefer static classes, and if I need different behavior, I combine it with a dependency injection and a provider.. I don't know what pattern this is, or if it has a name, but it usually goes something like this:

public interface IFooProvider {
  Bar FooBar();
}

public static class Foo {
  public static readonly IFooProvider FooProvider { get; set; }
  public Bar FooBar() { return FooProvider.FooBar(); }
}

Then I just make sure to set the provider somewhere in my init method. It's easy enough to add lazy initialization if you want to by setting the default provider at class initialization. Best of all, it allows you to change the behavior while still getting the aesthetic of using static classes.

Answer 5

1. A Singleton can implement interfaces, inherit from other classes
2. A Singleton can be initialized lazily or asynchronously and loaded automatically by the .NET Framework CLR (common language runtime) when the program or namespace containing the class is loaded. While a static class is generally initialized when it is first loaded and it will lead to potential class loader issues.
3. Singleton class follow the Object Oriented Principles
4. Singleton Objects stored on heap while static class stored in stack.
5. Singleton Objects can have constructor while Static Class cannot.
6. Singleton Objects can dispose but not static class
7. Singleton Objects can clone but not with static class

Answer 6

In many languages static classes lack useful features, like inheritance (and polymorphism more generally).

(Not that I'm advocating singletons.)