Singleton in Design Pattern

Hi,

I read the Singleton in the book << Design Patterns - Elements of Reusable Object-Oriented Software>>.

The Singleton class is define as :
class Singleton {
public:
static Singleton* Instance();
protect:
Singleton();
private:
static Singleton* _instance;
};

My question is why it uses protected constructor instead of private. Does it care about inheritance?

Any suggestion is welcomed.

Whilst the GOF book is very good, its also very dated now. Nowadays there are better solutions to the singleton problem. Check out the singleton facilities available in Loki and read the chapter on singletons in Modern C++ Design for a much more indepth discussion.

Quote:

---

Originally Posted by jianma

My question is why it uses protected constructor instead of private. Does it care about inheritance?

Any suggestion is welcomed.

---

The code shown in that GoF book are implementation suggestions only and not definitions of how the patterns must be implemented.

And yes, one of the stated benefits of using a Singleton (over an ordinary global data structure) is the possibility of using inheritance (see Consequences #3). Another maybe even more surprising benefit is the possibility of allowing more than one instance (see Consequences #4).

The best way to make use of the design patterns in my view is to understand the gist of them and then modify and implement them to fit each special situation. One quite popular Singleton implementation in C++ is the so called Meyer's Singleton:

http://www.devarticles.com/c/a/Cplus...tern-Part-I/4/

Finally note that even though the Singleton is one of the original design patterns this doesn't mean it should be used as much as possible. The Singleton still represents global data which should be avoided whenever possible because it increases coupling. Too much global data is bad even in the form of Singletons.

Thanks!

Doesn't look very good to be using a protected constructor here. Afterall, if there starts to be a derived class of this singleton, that would mean instantiation of more than one object of it (be it a direct object or as part of a sub-object of the derived class) which really beats the purposes and goes against the pattern's definition.

Quote:

---

Originally Posted by exterminator

Doesn't look very good to be using a protected constructor here. Afterall, if there starts to be a derived class of this singleton, that would mean instantiation of more than one object of it (be it a direct object or as part of a sub-object of the derived class) which really beats the purposes and goes against the pattern's definition.

---

Totally disagree.

Code:

---

class Singleton
{
  // impl
};

class Cars : public Singleton
{
public:
  list<string> GetCars();
};

class Fruits : public Singleton
{
public:
  list<string> GetFruits();
};

---

Ok, it's a bad example, but it's not hard to see that you may want multiple singletons that are unrelated

Quote:

---

Originally Posted by exterminator

Doesn't look very good to be using a protected constructor here. Afterall, if there starts to be a derived class of this singleton, that would mean instantiation of more than one object of it (be it a direct object or as part of a sub-object of the derived class) which really beats the purposes and goes against the pattern's definition.

---

Yet another uninformed factoid about design patterns. See consequences #3 and #4 of the Singleton definition in the GoF book (I mentioned in my previous post).

Quote:

---

Originally Posted by Amleto

Totally disagree.

Code:

---

class Singleton
{
  // impl
};

class Cars : public Singleton
{
public:
  list<string> GetCars();
};

class Fruits : public Singleton
{
public:
  list<string> GetFruits();
};

---

Ok, it's a bad example, but it's not hard to see that you may want multiple singletons that are unrelated

---

I don't know. It's hard for me to comment on the above class but provided they are as-is, it just shows an example of inheritance where say the base class definition is hidden to the users of the class. That would serve the purpose. Just because the base class is named Singleton doesn't necessarily mean it is one. And may be in the above, you would call the Cars and Fruits as Singleton class rather than the base class.

Quote:

---

Originally Posted by nuzzle

Yet another uninformed factoid about design patterns. See consequences #3 and #4 of the Singleton definition in the GoF book (I mentioned in my previous post).

---

Of couse, there can be more instances but then that's just a consequence and I don't know what GoF define the consequences but that most probably they don't consider those to form the definition of the pattern itself and hence mark it as a consequence or a way to extend the pattern to achieve something more/different. So, that, even though its valid, doesn't become the definition of Singleton itself. If you feel comfortable terming it that way, so be it but I would consider it to be an extension or a variation to the fundamental pattern.

There can be variables of basic patterns, and to term those variations as the pattern itself would probably be too confusing. Hence, even they themselves don't define singletons as class that can have 1 or more instances or say controlled number of instances. Probably there was scope of defining that variation or consequence as something else to make it clearer and less confusing and going against the basic definition and hence we got the term so called multi-tons although this term doesn't feature in their book. But I would consider this to be a much cleaner way to define things.

The singleton class can be templated passing in the derived class name by CRTP making each base subobject distinct and different. ie singleton<fruit> would be unrelated to singleton<cars>. Now they become real singletons again.