Reputation: 4308
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 there is a good reason. Otherwise, they wouldn't be used, obviously.
Upvotes: 52
Views: 26415
Reputation: 595
Upvotes: 8
Reputation: 69
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.
Upvotes: 6
Reputation: 81516
One good reason for preferring a singleton over a static class (assuming you have no better patterns at your disposal ;) ), is swapping out one singleton instance with another.
For example, if I have a logging class like this:
public static class Logger {
public static void Log(string s) { ... }
}
public class Client {
public void DoSomething() {
Logger.Log("DoSomething called");
}
}
It works really well, but what if Logger writes things to a database, or writes output to the console. If you're writing tests, you probably don't want all those side-effects -- but since the log method is static, you can't do anything except.
Ok, so I want to hot-swap my Log method for testing. Go go gadget singleton!
public class Logger {
private static Logger _instance;
public static Logger Instance
{
get
{
if (_instance == null)
_instance = new Logger();
return _instance;
}
set { _instance = value; }
}
protected Logger() { }
public virtual void Log(string s) { ... }
}
public class Client {
public void DoSomething() {
Logger.Instance.Log("DoSomething called");
}
}
So you can define a TestLogger : Logger
with an empty Log
method, then set an instance of your test logger to the singleton instance for tests. Presto! You can hotswap your logger implementation for tests or production without affecting client code.
Upvotes: 37
Reputation: 5310
Singletons are often preferred to global variables because:
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.
Upvotes: 11
Reputation: 65116
Even though IMHO the singleton pattern is a rather overused pattern, it does sometimes offer benefits, such as:
Upvotes: 7
Reputation: 6054
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.
Upvotes: 2
Reputation: 48583
In many languages static classes lack useful features, like inheritance (and polymorphism more generally).
(Not that I'm advocating singletons.)
Upvotes: 3