I've always recognized the importance of utilizing design patterns. I'm curious as to how other developers go about choosing the most appropriate one. Do you use a series of characteristics (like a flowchart) to help you decide?

For example:

If objects are related, but we do not want to specify concrete class, consider Abstract

When instantiation is left to derived classes, consider Factory

Need to access elements of an aggregate object sequentially, try Iterator

or something similar?

  • 9
    What do you think the importance is? programmers.stackexchange.com/questions/70877/…
    – pdr
    Commented Feb 6, 2014 at 0:00
  • 1
    I think the importance is in the ability to recognize the most appropriate and holistic pattern, to be able to ultimately communicate that to other developers. If that makes sense?
    – Carl Sagan
    Commented Feb 6, 2014 at 0:11
  • I agree with @pdr. I think about what I need to do, and remembering the name of the pattern helps me name the Class so others know what it does as well. Commented Feb 6, 2014 at 1:08
  • 4
    Indeed. This could be simply boiled down to "How do you choose the right design?". First, there's no right design, just plenty of wrong ones. Beyond that, it comes with piles experience (picking the wrong ones).
    – Telastyn
    Commented Feb 6, 2014 at 1:18
  • How do you go about choosing not to use any design pattern? How do you go about choosing a particular design when it isn't a design pattern?
    – Pablo H
    Commented Sep 20, 2021 at 14:14

2 Answers 2


A key misconception in today's coding world is that patterns are building blocks. You take an AbstractFactory here and a Flyweight there and maybe a Singleton over there and connect them together with XML and presto, you've got a working application.

They're not.

Hmm, that wasn't big enough.

Patterns are not building blocks

That's better.

A pattern is something that you use when you find that you've got a problem - you need some flexibility that the pattern provides, or that you've stumbled across when you are making a little language in the config file and you say "wait a moment, stop, this is its own interpreter that I'm writing — this is a known and solved problem, use an Interpreter pattern."

But note there, that it's something that you discover in your code, not something you start out with. The creators of Java didn't say "Oh, we'll put a Flyweight in the Integer" at the start, but rather realized a performance issue that could be solved by a flyweight.

And thus, there's no "flow chart" that you use to find the right pattern. The pattern is a solution to a specific type of problem that has been encountered again and again and the key parts of it distilled into a Pattern.

Starting out with the Pattern is like having a solution and looking for a problem. This is a bad thing: it leads to over engineering and ultimately inflexibility in design.

As you are writing code, when you realize that you're writing a Factory, you can say "ah ha! that's a factory I'm about to write" and use your knowledge of knowing the Factory pattern to rapidly write the next bit of code without trying to rediscover the Factory pattern. But you don't start out with "I've got a class here, I'll write a factory for it so that it can be flexible" — because it won't.

Here's an excerpt from an interview with Erich Gamma (of Gamma, Helm, Johnson, and Vissides): How to Use Design Patterns:

Trying to use all the patterns is a bad thing, because you will end up with synthetic designs—speculative designs that have flexibility that no one needs. These days software is too complex. We can't afford to speculate what else it should do. We need to really focus on what it needs. That's why I like refactoring to patterns. People should learn that when they have a particular kind of problem or code smell, as people call it these days, they can go to their patterns toolbox to find a solution.

The best help for the "what to use, when" is likely the Wikipedia page for software design pattern - the "Classification and list" section describes the category each pattern is in and what it does. There's no flowchart; the description there is probably the best you'll find as a short snippet for "what to use, when."

Note that you'll find different patterns in different areas of programming. Web design has its own set of patterns while JEE (not web design) has another set of patterns. The patterns for financial programming are completely different to those for stand alone application UI design.

So any attempt to list them all is inherently incomplete. You find one, figure out how to use it and then it eventually becomes second nature and you don't need to think about how or when to use it ever again (until someone asks you to explain it).

  • 16
    +1 for "solution looking for a problem." Knowing the patterns will allow you to skip the natural discovery of them when it turns out you need to solve a problem they happen to solve. Learning about them will probably help improve your coding and design skills, in the same way that reading other people's code or learning another programming language does. But you most definitely should not be actively trying to "fit patterns in" to your code.
    – gregmac
    Commented Feb 6, 2014 at 5:46
  • 2
    I always recommend developers starting to look at patterns to first familiarize themselves with design principles. Every pattern is an illustration of some of the principles of design (The 'SOLID' set of principles is just one example).
    – rpggio
    Commented Feb 20, 2014 at 6:32
  • 4
    Maybe you add a decorator and facade you'd have an app ;-) Said another way, the point of design patterns is to give us a name, a common language when discussing what we're building. It's shorthand for a stack of hard won development knowledge.
    – EBarr
    Commented Mar 19, 2014 at 20:23
  • 2
    Reading between the lines here, the steps to choosing a design pattern: 1. Always think critically of any code you're working in. 2. Abstract the specific code into a base problem 3. Does that problem have a known solution (design pattern)? 4. Yes, how do I apply that solution to my specifics? 5. Adapt the generic solution to the abstract problem, to create a solution to your specific problem.
    – CLo
    Commented May 29, 2014 at 19:32
  • @Chris that really sums it up. There's also nothing wrong with writing it without patterns and then refactoring the code into the appropriate pattern if the design needs it.
    – user40980
    Commented May 29, 2014 at 19:38

I ask myself:

  1. What problem am I trying to solve?
  2. Which software design pattern (if any) most closely solves the same problem, or provides a logical path towards solving my problem?
  3. Do I need the additional abstraction (and complexity) that the pattern provides, or is it over-engineering for my particular problem? Can the problem be solved in a simpler, more efficient way without the pattern?

The process of choosing a software pattern is not unlike the process of choosing a data structure, except that in choosing a data structure, you would evaluate the performance and memory characteristics of your problem, and choose the data structure that most closely fits those characteristics.

  • Ofcourse, that is some thing about experience and expert, instead of a blueprint or flow chart, and I do agree with you. But there must be some use full resources like an advanced cheat sheet in which it has been categorized, at least in case with the most important and frequent patterns like factory, etc. I am after such thing like a most well-known recommended situations in which you would better use a pattern. do u know such a resource out there on internet?! Commented May 28, 2016 at 22:22
  • 3
    @Trix: sourcemaking.com/design_patterns Commented May 28, 2016 at 22:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.