How do you know when to use design patterns? [closed]

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.