Anyone can read the GoF book to learn what design patterns are and how to use them, but what is the process for figuring out when a design pattern solves a problem? Does the knowledge of the pattern drive the design, or is there a way to figure out how a pattern can be used to change a design?
In other words, are there patterns for Patterns?
I would highly recommend reading Head First Design Patterns from O'Reilly. This explains how these patterns can be used in the real world.
I'd also add that don't try design too much with patterns in mind. More, look for "code smells" which a pattern might help solve.
Experience. Learn the patterns and real-world examples of their uses. Every time you have a design decision to make, think if a pattern you know would apply to it. Over time, you get better and you discover new ways to apply the patterns to a wider range of problems.
Another great book I found was:
Refactoring to Patterns
By showing when, where and how you can alter existing code to patterns, it gave me a much better understanding of the concepts, and an ability to identify where they can be used.
How did you learn when to use an if statement?
I liken it to that because its a larger construct that you need to know the ins and outs of before you can use it effectively. An if statement solves a class of problems needing branching. A bridge pattern solves a class of problems. I really don't view them any differently.
Design patterns are supposed to provide a structure in which problems can be solved. When solving a real problem, you have to consider many tiny variations of a solution to that problem to see whether any fits a design pattern. In particular, you will probably need to generalise your problem, or its solution, in order to make a design pattern fit.
The answer is, it's an art. Knowing the design patterns is certainly an important step. One way to get used to this sort of thing is to study applications of design patterns, not just the patterns. Seeing many different applications of one pattern can help you over time to get better at mapping a task onto a pattern.
If you know the patterns, then they become tools in your toolbox. When you look at a task, you select from your tools. At that point you should have a pretty good idea which tool is the best fit for a given problem. This is where formulas stop working and you actually do engineering work.
I agree that just learning the patterns is not enough. The problem with most books is that they do not provide real-world examples. I've heard that Head First Design Patterns, as some suggested earlier, is a good one.
Another thing is that most books are intentionally not language-specific, which may be both a good or a bad thing for you. However important is to understand a pattern in general, it is equally important to know how to implement it well. I've come across a book called C# 3.0 Design Patterns which devotes just about equal ink to both of these unseparable aspects.
I had this same question when I first encountered design patterns. I appreciated the concepts, but didn't know when or how to apply them. My initial approach was to look for applicability during the design phase. Once you have a block diagram and semi-clear responsibilities for each block, its not too hard to take the responsibilities and cross reference them with a decent reference book. Several good ones have been mentioned here, but the GoF one should be on your list. The next step is to look for improvements in the design based on what you see in the patterns.
Design Patterns? You're soaking in them!
There's nothing special about design patterns, they are merely patterns of design. All development uses design patterns. There are a certain set of design patterns in object oriented programming which are considered generally desirable and have become the canonical Design Patterns. But there are also many undesirable or otherwise indifferent design patterns (such as design anti-patterns) as well as undiscovered and/or undocumented patterns.
You can't avoid using patterns when programming. But you can become more aware of the patterns you are using and of when certain patterns are useful and when they are not. Studying the canonical Design Patterns from the GoF book will help, as will learning about code smells and refactoring. There's no one right answer for when a particular design or design pattern should be used, you need to build up experience in using and implementing them in order to know when and where to use which pattern.
Turn the question over: the pattern mtch you should be making is "what pattern fits my problem". Consider a really simple pattern, finding an element in an array. in C, it's something like
TYPE_t ary[SIZE] = // ... gets initialized somehow
size_t ix ; // Your index variable
for(ix=0; ix < SIZE; ix++){
if (ary[ix] == item) {
return ix ;
}
}
You don't look at the code and think "where can I use that", you look at the problem and say "do I know how to find an element in an array?"
With more extensive patterns is really works the same way. You need to have many many copies of a data structure that doesn't change often --- that makes you think "Flyweight." You want something that lives on both sides of a network boundary, you think Proxy.
When you study patterns, especially the GoF, ask yourself "what situations call for this pattern? Have I seen this pattern before? What could I have used this for in previous work? Where can I find an example of this in my own life?"
There's a core concept underlying patterns that most people don't grok. Don't think of them as data structures, or algorithms.
Instead, think of your code as people sending messages, like passing notes or sending letters, to each other. Each object is a 'person'.
The way that you'd organize the 'people' and the patterns they use to send messages to each other are the patterns.