Should we seal Singletons? Should we try to inherit from Singletons in the first place?

Question

Should a Singleton class be allowed to have children? Should we seal it? What are the pro's and con's?

For being able to inherit from a Singleton class, we would have to make the constructor protected instead of private. Now, that will be fine in c#, but the protected word in java gives both child-classes and package-classes access to the constructor. Which means not only classes that inherit from our Singleton can access the constructor but other classes in the same package can do it.

I'm a bit confused about all this facts. Maybe I am making a big fuss about nothing to worry about too much? Until now, I never had any necessity of trying to inherit from a Singleton, so maybe this is just an academic question!

Thanks

Answer 1

A better solution is to use an IoC Container framework to handle the "Singleton" (lifetime) aspect of the class. At that point you can use a POJO and simply inherit from it.

EDIT: Some links that may help:

• List of .NET Dependency Injection Containers (IOC)
• Open Source Inversion of Control Containers (Java)

Look for ones that handle lifetime management. You want to be able to configure the container (which acts like a generic factory) so that requests for instances of "Singleton" classes always return the same instance (at least for the same container). You generally only have one container instance at the highest level of your application.

Answer 2

If you can extend from a singleton, then it means that you can have more than one instance of it. This contradicts the whole singleton idea. Just make it a "normal" class and write the code around it accordingly that you instantiate it only once and use the same instance forever. If you need it to be. Dependency injection can help a lot in this.

Answer 3

Yes, Singletons should be sealed. No, they should not be inherited.

The reason is that the primary (really only) behaviour of a Singleton is to create an instance of itself at some predetermined time. Since this functionality is static, it can't be overridden, so it would have to be duplicated instead. Once you start duplicating, you have multiple instances of a singleton, which doesn't really make sense.

Either that or you end up with race conditions or other conflicts as the "derived" singletons fight for control over the global instance, which not only doesn't make sense, it's dangerous.

There are some hackish workarounds to the Singleton inheritance problem, but that is what they are - hacks. The Singleton pattern is not really suitable for inheritance.

Answer 4

If you want to use inheritance in conjunction with the singleton pattern, you should put the inheritable state and behaviour into an abstract base class and define the singletons as (final) subclasses.

Answer 5

Hmm, sounds like a question many of us got asked at school when learning about Singletons. I'd suggest reading the following links.

http://msmvps.com/blogs/jon_skeet/archive/2006/01/20/singleton-inheritance.aspx http://msdn.microsoft.com/en-us/library/84eaw35x.aspx

Many would strongly discourage inheriting from a singleton, but real-life programming often requires exactly such an approach. I personally would say, don't inherit from a singleton as a rule of thumb, but don't lock yourself into a design which blocks off such an approach. A pragmatic development approach is always the best approach...