- Forum
- General C++ Programming
- design patterns in c++
design patterns in c++
Guys, I have been learning design patterns.We used the Gang of four book, published in 1995.its a great book, but for some reason I think they don't explain well.It takes me a while to grasp the information.Which is not me.So, was wondering, May you please suggest great books about design patterns.Our instructor said we are going to do 23 or 24 design patterns, can't really recall.Now, we are at the observer and it took me a while to grasp it, even though I'm not sure whether I understand it as I think I do.Please help guys, books that made you understand design patterns. preferable with c++ examples
You might want to have a look at 'Head First Design Patterns'.
http://www.amazon.com/First-Design-Patterns-Elisabeth-Freeman/dp/0596007124
Aimed squarely at the run-of-the-mill Java programmer, it is typical of such books - goes on and on (with cartoons and other trivia) for page after page, laying the background, before it finally decides that it is time to get to the point. But unlike a lot of other books of this kind, when it does get to the point, it does a fair job of explaining the pattern. And no one, absolutely no one, can complain that the learning curve is too steep.
There is a C++ translation of the book available on sourceforge. http://sourceforge.net/projects/hfdp-cpp/
Haven't read it, but it has a good user rating. Perhaps, you would want to have a look at that too.
http://www.amazon.com/First-Design-Patterns-Elisabeth-Freeman/dp/0596007124
Aimed squarely at the run-of-the-mill Java programmer, it is typical of such books - goes on and on (with cartoons and other trivia) for page after page, laying the background, before it finally decides that it is time to get to the point. But unlike a lot of other books of this kind, when it does get to the point, it does a fair job of explaining the pattern. And no one, absolutely no one, can complain that the learning curve is too steep.
There is a C++ translation of the book available on sourceforge. http://sourceforge.net/projects/hfdp-cpp/
Haven't read it, but it has a good user rating. Perhaps, you would want to have a look at that too.
This is a good site which describes quite a few design patterns very well.
http://sourcemaking.com/design_patterns
http://sourcemaking.com/design_patterns
What are these design patterns? Are you talking about different ways to design a program?
Just wondering, I am curious because I am not currently in Computer Science class... yet.
Just wondering, I am curious because I am not currently in Computer Science class... yet.
Last edited on
Design patterns are re-usable solutions to frequent problems. You probably would recognize a few from your own derivations. Many of them have even been implemented in the STL.
There are 3 main kinds of design patterns: Creational, structural, and behavioral.
Creational design patterns tell us how our objects are created. For example implementing inheritance to provide a common base for templated classes, leaving objects in a pool to be re-used later without the need for object creation, or making classes "NONCOPYABLE".
Structural design patterns represent the contents of an object. For example, we may use a facade class to represent an entire subsystem and all interfaces for that subsystem. We may use a bridge to seperate an objects implementation from its interface (pimpl). We may use an adapter to provide a single common interface for several different objects (ex Qt provides one interface independent of the platform).
Behavioral design patterns describe communication and implementation. We may use a NULL pointer to describe when a pointer doesn't point to anything. We may implement a "chain of responsibility" where we send a message along a chain of objects, and the first object with the ability to handle it, takes it and otherwise recursively passes it on. State machines help us to centralize the mode logic of a particular object.
These are quite useful and it's not a bad thing to be familiar with. The fact that I even knew about specific design patterns has helped me at work in finding a quick and effective solution to a problem.
There are 3 main kinds of design patterns: Creational, structural, and behavioral.
Creational design patterns tell us how our objects are created. For example implementing inheritance to provide a common base for templated classes, leaving objects in a pool to be re-used later without the need for object creation, or making classes "NONCOPYABLE".
Structural design patterns represent the contents of an object. For example, we may use a facade class to represent an entire subsystem and all interfaces for that subsystem. We may use a bridge to seperate an objects implementation from its interface (pimpl). We may use an adapter to provide a single common interface for several different objects (ex Qt provides one interface independent of the platform).
Behavioral design patterns describe communication and implementation. We may use a NULL pointer to describe when a pointer doesn't point to anything. We may implement a "chain of responsibility" where we send a message along a chain of objects, and the first object with the ability to handle it, takes it and otherwise recursively passes it on. State machines help us to centralize the mode logic of a particular object.
These are quite useful and it's not a bad thing to be familiar with. The fact that I even knew about specific design patterns has helped me at work in finding a quick and effective solution to a problem.
interesting... I typically create my programs through improvision, and they work exceptionally well.
I suppose the reason to know them would be to save time? I can't think of any reason why a programmer can't simply 'invent' these solutions.
I suppose the reason to know them would be to save time? I can't think of any reason why a programmer can't simply 'invent' these solutions.
If you keep improvising it keeps getting harder, as you make a bigger and bigger tangled mess (unless you refactor your entire code base every time you add more stuff, which gets very impractical very quickly). Using a design pattern ensures that no matter the scale of a project the complexity stays the same. For small projects the complexity is a little high, but for very large projects of production quality the complexity is very low.
Last edited on
IWishIKnew. There's nothing stopping you from inventing these. They are patterns which means that people already use them, someone has just identified them as a frequent solution to a common problem. By identifying and cataloguing it, it makes the rest of us aware of other common solutions.
When I first learned about them, I had realized that I'm already using quite a few of them.
Note that "why can a programmer can't simply invent these solutions" is a bit of a strange argument. A programmer could invent the STL instead of learning how to use the existing one. A programmer could invent their own C++ wrapper for Win32 and WinSock2 instead of using SFML. Some of the design patterns are quite complex, and being aware of them lets you implement them much easier than figuring it out from scratch. That's especially true when you have a deadline or a competency expectation from your boss.
When I first learned about them, I had realized that I'm already using quite a few of them.
Note that "why can a programmer can't simply invent these solutions" is a bit of a strange argument. A programmer could invent the STL instead of learning how to use the existing one. A programmer could invent their own C++ wrapper for Win32 and WinSock2 instead of using SFML. Some of the design patterns are quite complex, and being aware of them lets you implement them much easier than figuring it out from scratch. That's especially true when you have a deadline or a competency expectation from your boss.
closed account (3qX21hU5)
Design patterns in programming are essentially just words that programmers made up to better communicate solutions to common problems they have ran into with other programmers.
They aren't something that you "have" to use/learn though the chances are you are already using them without even knowing you are using them.
Now with that said learning common design patterns can help you though because it gives you a toolbox full of designs to help solve common problems that you will run into in your programs. But let me stress that you should only use design patterns if they fit a certain problem you have and not the other way around.
By that I mean don't at the start of a project say well I am going to do this project using XYZ pattern because it is cool and I like it. Only use them when they are the best choice for a certain problem and make sure you put thought into why you need to use it.
Basically don't design your whole project around specific design patterns just so you can say you used them.
The only reason I mention this is because so many people when they first find out about design patterns (Myself included) go way overboard in using them when they aren't needed and it ends up making the program way more complicated then it needed to be and much more unmanageable.
They aren't something that you "have" to use/learn though the chances are you are already using them without even knowing you are using them.
Now with that said learning common design patterns can help you though because it gives you a toolbox full of designs to help solve common problems that you will run into in your programs. But let me stress that you should only use design patterns if they fit a certain problem you have and not the other way around.
By that I mean don't at the start of a project say well I am going to do this project using XYZ pattern because it is cool and I like it. Only use them when they are the best choice for a certain problem and make sure you put thought into why you need to use it.
Basically don't design your whole project around specific design patterns just so you can say you used them.
The only reason I mention this is because so many people when they first find out about design patterns (Myself included) go way overboard in using them when they aren't needed and it ends up making the program way more complicated then it needed to be and much more unmanageable.
Last edited on
I think design patterns are not all that helpful until you've been programming for some period of time and have encountered a few of them on your own (although, maybe you didn't recognize them when you did.) I think it becomes easier, then, to hold a higher level view of what you're doing when you've learned to recognize those patterns and it definitely becomes easier to discuss with others what your code is doing when you have that vocabulary in common, and I think that is the primary utility of design patterns - to facilitate the exchange of ideas.
Topic archived. No new replies allowed.