0

According to the GOF Design patterns' book, singleton pattern should be used when:

  • there must be exactly one instance of a class, and it must be accessible to clients from a well-known access point

  • when the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code

could someone clarify the second point?

|improve this question|||||
  • 1
    erm maybe some context? – Ewan Nov 17 '18 at 16:38
  • @Erwan i found it on a popular repo of java design patterns with no context : github.com/iluwatar/java-design-patterns/tree/master/singleton – isqo Nov 17 '18 at 16:40
  • 1
    It's a quote from Go4, one of the points under the Applicability section ("Use Singleton when..."). – Filip Milovanović Nov 17 '18 at 16:40
  • 1
    @isqo We don't support questions that require reading the comments or visiting links to answer. Please edit these clarifications into the question. – candied_orange Nov 17 '18 at 16:44
  • 2
    Hmm, it's weird that the repo says you should use singleton "when the instance should be extensible by subclassing" yet goes on to list one of the consequences of using it as "Makes it almost impossible to subclass". – candied_orange Nov 17 '18 at 17:07
4

This is a quote from the Go4 book, and it's the second of two points under the Applicability section ("Use the Singleton pattern when...")

This point is not really Singleton-specific; it just means that the client code is written against the base class interface, and is thus decoupled from (is not aware of) the concrete Singleton implementation. This is just dependency inversion present in many other patterns. I guess they included it as, if you don't have a need for subclassing, you can just use a static class (as in C#), or a bunch of free methods + some global state, or something along those lines.

In this approach, one of the problems is how to configure the GetInstance() method (or equivalent) to return the correct concrete implementation.

That said, note that Singleton is considered by many to be an antipattern, the main reason being that a Singleton, as normally implemented, is essentially a global variable, so all the code that uses it can become implicitly coupled.

|improve this answer|||||
  • it just means that the client code is written against the base class interface, you mean base singleton class interface ? – isqo Nov 17 '18 at 17:24
  • @isqo: Yes. (And I mean interface as in "set of public members", and not the language construct (so, not the thing where you declare a type using the interface keyword, as in C# or Java). The client code is the code that uses the singleton, and all it does with it is always using the public methods of the singleton base class. – Filip Milovanović Nov 17 '18 at 17:29
1

Can anyone clarify the second point? probably not.

The GoF paper goes on to say:

Subclassing the Singleton class. The main issue is not so much defining the subclass but installing its unique instance so that clients will be able to use it. In essence, the variable that refers to the singleton instance must get initialized with an instance of the subclass.

It then goes on to suggest three ways of doing this. None of which is really any good.

  1. Put an If statement in the Singleton class

  2. Put the GetInstance for the subclass singleton in a different class and link the class you want to use during compilation

  3. Add a Register function which sets the singleton up and can take a subclass.

My advice would be to ignore the second point. Using a singleton in the modern meaning of the term means you can't replace it with a subclass without effectively editing the original class.

I should make an important note though. If you go the register route you are effectively creating a DI container for that single class. Instead of using the singleton pattern, you should register the class you wish to use as a singleton, (different containers call this different things) in your DI container.

This doesn't really prevent two instances of the class existing at the same time, but its the best alternative.

|improve this answer|||||
  • Good point about DI containers; the book actually describes the approach in terms that evoke that image, in the sense that the seeds behind the idea of DI containers are there - although the language can be considered somewhat antiquated: "A more flexible approach uses a registry of singletons. Instead of having Instance define the set of possible Singleton classes, the Singleton classes can register their singleton instance by name in a well-known registry." – Filip Milovanović Nov 17 '18 at 17:25

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.