How do you know when to use design patterns?

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.

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.

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.

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?"

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.

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.

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.

A design pattern is a generic description on how to solve a common problem. There're 2 things we should pay attention to:

First, it is a Generic description; it's not the concrete solution, and it's not a complete recipe either, it's just a description on how the solution would look like in order to approach a common problem.

Second, the problem is question is a common problem:, that means this problem has been encountered many times before, and over time people developed a description for how an ideal solution can be applied to this commonly repeated problem.

So, if you're encountering a new problem that's not common, try not to use design patterns to solve it, or at least don't make design patterns your tool to just solve any kind of problem you face.