-
March 17th, 2011, 02:30 PM
#1
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.
-
March 17th, 2011, 06:06 PM
#2
Re: Singleton in Design Pattern
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.
Get Microsoft Visual C++ Express here or CodeBlocks here.
Get STLFilt here to radically improve error messages when using the STL.
Get these two can't live without C++ libraries, BOOST here and Loki here.
Check your code with the Comeau Compiler and FlexeLint for standards compliance and some subtle errors.
Always use [code] code tags [/code] to make code legible and preserve indentation.
Do not ask for help writing destructive software such as viruses, gamehacks, keyloggers and the suchlike.
-
March 18th, 2011, 12:49 AM
#3
Re: Singleton in Design Pattern
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.
Last edited by nuzzle; March 18th, 2011 at 10:47 AM.
-
March 18th, 2011, 02:51 PM
#4
Re: Singleton in Design Pattern
-
March 19th, 2011, 06:56 AM
#5
Re: Singleton in Design Pattern
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.
Can you help me with my homework assignment?, Before you post!, Use code tags, How to post!, Codeguru technical FAQs, C++ FAQ Lite, Stroustrup: C++ Style and Technique FAQ, Guru of the Week, Comeau C and C++ FAQs, Comeau C++ Templates FAQs, CUJ @ DDJ, Spam threshold
My Blogs : Learning C++ is fun | Abnegator's reflections
Open Threads : C++ Aha! Moments | Nature of work in C++?
-
March 19th, 2011, 01:22 PM
#6
Re: Singleton in Design Pattern
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
-
March 20th, 2011, 01:36 AM
#7
Re: Singleton in Design Pattern
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).
Last edited by nuzzle; March 20th, 2011 at 01:44 AM.
-
March 20th, 2011, 08:01 AM
#8
Re: Singleton in Design Pattern
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.
Can you help me with my homework assignment?, Before you post!, Use code tags, How to post!, Codeguru technical FAQs, C++ FAQ Lite, Stroustrup: C++ Style and Technique FAQ, Guru of the Week, Comeau C and C++ FAQs, Comeau C++ Templates FAQs, CUJ @ DDJ, Spam threshold
My Blogs : Learning C++ is fun | Abnegator's reflections
Open Threads : C++ Aha! Moments | Nature of work in C++?
-
March 20th, 2011, 08:05 AM
#9
Re: Singleton in Design Pattern
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.
Can you help me with my homework assignment?, Before you post!, Use code tags, How to post!, Codeguru technical FAQs, C++ FAQ Lite, Stroustrup: C++ Style and Technique FAQ, Guru of the Week, Comeau C and C++ FAQs, Comeau C++ Templates FAQs, CUJ @ DDJ, Spam threshold
My Blogs : Learning C++ is fun | Abnegator's reflections
Open Threads : C++ Aha! Moments | Nature of work in C++?
-
March 20th, 2011, 08:55 AM
#10
Re: Singleton in Design Pattern
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.
Get Microsoft Visual C++ Express here or CodeBlocks here.
Get STLFilt here to radically improve error messages when using the STL.
Get these two can't live without C++ libraries, BOOST here and Loki here.
Check your code with the Comeau Compiler and FlexeLint for standards compliance and some subtle errors.
Always use [code] code tags [/code] to make code legible and preserve indentation.
Do not ask for help writing destructive software such as viruses, gamehacks, keyloggers and the suchlike.
Tags for this Thread
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|