Click here to Skip to main content
15,887,683 members
Please Sign up or sign in to vote.
1.00/5 (2 votes)
See more:
Hello friends,

i am working on Design patterns in c++ , i have read very interesting article on creation patterns "Design Patterns 1 of 3 - Creational Design Patterns" by
Kanasz Robert it is very good article..
my self in intial phase of project on hotel checkin system need more detailed understanding on this area.

can any body suggest me on which area i have to focus more in creational patterns.i.e; Abstract factory, Builder, Factory Methods, Prototype and singleton.

Thank you in advance.

What I have tried:

I am working on abstract factory intially
Posted
Updated 2-Mar-16 2:15am
Comments
nv3 1-Mar-16 16:25pm    
Focus on all that you need for your project -- as simple as that. Nobody can tell you what patterns you are going to need in your project. You will know, once you need them.

It's a sad fact of life for people writing patterns books that good C++ doesn't need creational patterns that often. Do a search for "parametrise from above" and you'll see the pattern that most good C++ [1] uses. Create objects automatically as you need them and make sure that only the piece of code that creates the object knows what its concrete class is - everything else uses a reference to an interface.

Another thing to consider is that some patterns advocated at the beginning of the patterns movement (especially singleton) are actually anti-patterns because they're a great way of introducing memory leaks, race conditions and who knows what else if you use them in multi-threaded code. Other patterns if over applied (e.g. builder) can make your code to create objects unreadable. Factory and Abstract factory can be very useful if you need to create objects based on information gathered from a variety of different scopes. However most programs don't need that complexity of design and overuse of these patterns can make your code look like the worst excesses of COM-mania from the early 90s where you spend 3/4 of your time writing boiler plate to support the pattern for very little reward.

So the best thing to do is identify the entities your program's going to need, make classes to represent them and see if any benefit from being created in a fashion that's not "bung it on the stack and use a reference to an interface." If that's the case then look at a book on patterns and see if anything fits.

[1] At least C++ written using an OO style, functional programming in C++ looks a bit different.
 
Share this answer
 
Comments
Arthur V. Ratz 20-Mar-16 11:25am    
5.
Just think of that: if one of those patterns would be a "perfect" one to be used everywhere, don't you think that all other creational patterns would be long forgotten and would never appear in modern publications and encyclopedias?

That simple practical reasoning suggests: there is no a silver bullet. You should start with the architecture of your project, starting your focus from the goals of your project. That should lead you to a good selection. Besides, who told you that you have to use one single creational design pattern throughout the whole project? What makes you thinking that you cannot combine the approaches, or simply use different patters for different classes, layers or sub-systems?

You did not share enough information with us to make a choice for you. You are the one who needs to make the choice.

But even that is not the most important thing. More importantly, you have to remember that using one or another design pattern cannot be one of your goals. Never. They are published to help your with the decisions on your product, not that your product should play the role of promoter of those patters. Patters, if any, always come next. I strongly advise to read my past answer, "forget design patterns" answer on a related topic: Please suggest me some basic C++ project with design patters[^].

If you read it, you will see that "forget" is not what I really mean (this is a figure of speech). I just try to explain, among other things, how to rationally take those design patterns. Always remember that using those design patterns is not your obligation.

—SA
 
Share this answer
 
v2
Comments
Arthur V. Ratz 20-Mar-16 11:25am    
5.
Sergey Alexandrovich Kryukov 20-Mar-16 12:20pm    
Thank you, Arthur.
—SA

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900