Question

Using a Singleton class guarantees one instance of a class to give control to the programmer. Really useful.

I was wondering if for example a Singleton Interface existed in a given framework to bypass the need to create/add one explicitly?

Would be handy to decalre:

public sealed class MySingleton : ISingleton  //or a different class 
    { ... }

And then expect the class to only ever be instantiated once.

Is this a good idea, or am I thinking a bit off the mark? 🙂

Answer 1

I was wondering if for example a Singleton Interface existed in a given framework to bypass the need to create/add one explicitly?

It doesn’t and can’t exist. A singleton basically requires a static Singleton getInstance() method, but because it’s static, it cannot be definied as an abstract (interface) method. It also makes sense, there can be only one singleton implementation, not multiple. Abstracting it is pointless.

You’ll need to boilerplate complete singletons yourself. I however highly question how that’s useful. It’s certainly not its sole purpose to prevent stackoverflow or memory errors. Writing good code prevents that. Singletons are only useful if you want to have the enduser to deal with the same instance all the time. Which can be done as good without the singleton pattern by the way. Either just declare it static or make use of the "application scope" concept the average framework can provide you.

Instead of singletons, rather look for inversion of control (dependeny injection). That’s by the way also exactly what Spring is doing. They do not use "pure" singletons. It was a poor word choice they made.

See also:

• Singletons are evil
• Patterns I hate #1: Singleton
• Inversion of Control and Dependency Injection pattern
• A Spring Singleton is not a Singleton