0

When do we need to subclass a Singleton class or in other words, is it good to subclassing a Singleton?

If its generally allowed what would be the pros and cons and how to handle or get instance from sub class?

It would be nice if you can give some examples snippets in java. Doesnt it break the single responsibility principal and make the app less testable and lead to a complicated state?

  • Did you already read this? – πάντα ῥεῖ Jun 6 '18 at 18:00
  • There are reasons for subclassing and there are reasons to use singletons. What makes you think there is a dependency? – Martin Maat Jul 24 at 16:37
10

There are very few reasons to subclass a singleton. The only potentially acceptable reason I can think of is if you have platform specific implementations. The important thing is that you don't add new singletons for the same thing. The way it would work is like this:

public class MySingleton {
    private static MySingleton _instance;

    static {
        // Detect platform
        switch(platform) {
            case Win32:
                _intance = new Win32Singleton();
                break;
            case Ubuntu:
                _instance = new UbuntuSingleton();
                break;
            default:
                _instance = new MySingleton();
                break;
        }
    }

    public static MySingleton getInstance() { return _instance; }

    protected MySingleton() {}
}

Essentially, your initializer is a factory to instantiate the appropriate instance of the singleton, but the following things must remain true:

  • Only one place to access your singleton (the root class)
  • Your constructors are protected or package accessible

However

In cases where you know that you will have platform specific implementations it's just more honest to work with a factory to get you a working instance for what you need and not worry about the whole Singleton thing. Singletons are (still) overused even when there is no real driving reason for it.

Any time you design a singleton to be subclassed you introduce a lot of complexity that wouldn't exist if you just allowed multiple instances.

  • I don't disagree with your answer (it's good: +1) but one of the little known nuances about the original GoF Singleton pattern is that subclassing was part of the point of it. It's not really front-and-center in the description but if you look at the example code, the Singleton class is polymorphic. – JimmyJames Jul 24 at 19:00
  • Yep. All I said was that it is rare to have that need. I did have to deal with something like that with a platform specific API in a past project that I don't remember too many details on. That's why my example code had that particular use case documented. – Berin Loritsch Jul 24 at 19:54
0

I’ve seen implementations where there is an abstract base class named “Singleton” (and that’s not an example name, it’s the name for this class), and every actual singleton class is a subclass of “Singleton”. So the usual definition what a singleton class is applies only to the subclasses. It’s a matter of taste, but not particularly good or bad.

There’s also a different point of view: We shouldn’t worry about singleton classes but about objects that are used for one specific purpose. That are created (often by a factory) when they are needed, reused as needed, and that exist until the application dies. Exactly what instances of singleton classes do, but no restriction that no two of these objects belong to the same class. That makes your question then irrelevant.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.