Being an IT student, I was recently given some overview about design patterns by one of our teachers. I understood what they are for, but some aspects still keep bugging me.

Are they really used by the majority of programmers?

Speaking of experience, I've had some troubles while programming, things I could not solve for a while, but Google and some hours of research solved my problem. If somewhere in the web I find a way to solve my problem, is this a design pattern? Am I using it?

And also, do you (programmers) find yourself looking for patterns (where am I supposed to look, by the way?) when you start the development? If so, this is certainly a habit that I must start to embrace.

UPDATE: I think when I ask if programmers do use them, I'm asking if when you have a problem to solve you think "Oh, I should use that pattern".

  • 7
    Not an exact duplicate question, but my answer would be the same. programmers.stackexchange.com/questions/70877/…
    – pdr
    Mar 28, 2012 at 9:46
  • 4
    Most of that overrated, overhyped "design patterns" are only relevant to the OOP programming. And there are many good reasons to stay away from OOP for as long as possible.
    – SK-logic
    Mar 28, 2012 at 11:07
  • 5
    I find myself using Big Ball of Mud more often than I'd like. Just kidding.
    – sashoalm
    Mar 28, 2012 at 14:17
  • The only answer is yes with the conditional statement of "When appropriate"
    – Rig
    May 16, 2012 at 18:18

13 Answers 13


When I was a novice programmer, I loved design patterns. I didn't just use design patterns. I inflicted them. Wherever and whenever I could. I was merciless. Aha! Observer pattern! Take that! Use a listener! Proxy! AbstractFactory! Why use one layer of abstraction when five will do? I've spoken to many experienced programmers and found that just about everyone who reads the GoF Book goes through this stage.

Novice programmers don't use design patterns. They abuse design patterns.

More recently, I find that keeping principles like the Single Responsibility Principle in mind, and writing tests first, help the patterns to emerge in a more pragmatic way. When I recognise the patterns, I can continue to progress them more easily. I recognise them, but I no longer try to force them on code. If a Visitor pattern emerges it's probably because I've refactored out duplication, not because I thought ahead of time about the similarities of rendering a tree versus adding up its values.

Experienced programmers don't use design patterns. Design patterns use them.

  • 2
    @schlingel - Why are you calling the OP Sir?
    – Oded
    Mar 28, 2012 at 19:34
  • 11
    @Oded I reserve my right to be called "Sir" under these circumstances and enjoy it.
    – Lunivore
    Mar 28, 2012 at 22:27
  • 3
    Sir, yes sir. No offence meant!
    – Oded
    Mar 28, 2012 at 22:40
  • 1
    In Soviet Russia.. :)
    – Sorantis
    Mar 29, 2012 at 11:10
  • 6
    Good answer, but in the last line you tried to be profound, but it is nonsensical. How about "Experienced programmers don't choose design patterns, they let them happen." Mar 29, 2012 at 13:22

Whether one recognizes them or not, most programmers do use patterns.

On the day to day work however, one does not start programming with a pattern in mind - one recognizes that a pattern has emerged in code and then names it.

Some of the common patterns are built into some languages - for example, the iterator pattern in built into C# with the foreach keyword.

Sometimes you already know the pattern you will be using as a common solution to the problem at hand (say the repository pattern - you already know you want to represent you data as an in-memory collection).

  • 13
    That's pretty much what I was going to say, patterns are a language to help programmers communicate design and implementation ideas, not a set of programming lego bricks which can be slotted together to implement a system.
    – Mark Booth
    Mar 28, 2012 at 10:08
  • 27
    @DeadMG Why is that? Mar 28, 2012 at 10:50
  • 11
    @DeadMG: I must have been blinded by the blindingly stupid idea - I can't see why you think it's stupid ;-)
    – Treb
    Mar 28, 2012 at 11:48
  • 2
    @root45 - You see friend, the foreach construct makes programming too easy. How can one feel superior to others if a complex task like iterating over a collection is easy? I for one still code in assembly for all my CRUD apps. Clearly the sentiment of @DeadMG is one of pure pragmatic genius. Mar 29, 2012 at 1:14
  • 8
    @DeadMG - LINQ wasn't around when .NET 1.0/1.1 was. yield didn't exist then either. Do you think that breaking old code by removing a keyword is a better option?
    – Oded
    Mar 29, 2012 at 8:29

As implied by the answer pdr linked: design patterns are names given to things people were doing anyway, intended to make it easier for people to discuss those things.

In general it's worth learning them when starting out, because they give you some insight into solutions people have found to work, so you can build on years of experience, and trial & error.

The discussion of motivating problems included with patterns may give you insight into good ways to attack your problem in the first place, but unless your pattern knowledge lets you recognize there is a well-known existing solution, you still need to focus on just solving the problem first.

If it turns out to use one or more existing patterns then great, you have ready-made names that will make it easier for others to understand your code.

  • +1 for a significant summation of what I wanted to say: Focus on the problem, and then, and only then, if the problem looks like one a pattern solves, apply the pattern. Mar 28, 2012 at 12:39
  • 2
    +1 for stating the true fact that design patterns are names given to things people were doing anyway.
    – miraculixx
    Dec 20, 2012 at 0:27

Generally speaking, no. There are times when patterns emerge from my code, but in general, I don't look for them and I certainly don't say "Oh, the Bridge Pattern would solve my problem!".

Here's the thing. Most patterns are abused and misused without people ever considering if they're good design. Patterns are not atoms. Code is not comprised of X permutation of patterns. Not to mention that not all patterns are actually good ideas, or that some languages have language-level solutions that are vastly superior to some patterns.

  • +1: I agree that patterns sometimes are misused. Sometimes I see code where the programmer has used a pattern just because he or she knew it and thought it was cool, but that made the code just unnecessarily complex and hard to read. Like cracking a nut with a bulldozer. Regarding language-level solutions, isn't a language-level solution just a pattern that is directly supported by the language? Or what is the difference?
    – Giorgio
    Mar 28, 2012 at 18:40
  • 1
    @Giorgio: Framed another way, some patterns are used to work around the fact that the language lacks a way to express a certain thing neatly.
    – Daenyth
    May 16, 2012 at 16:38

yes, most programmers I've ever encountered use the most common pattern there is, the Big Ball of Mud. They usually start out with well-designed architectures, but usually end up here, especially if they start to think "we must use design patterns" all over the place and refactor mercilessly.

  • 2
    The link made my day Mar 29, 2012 at 7:43
  • 1
    Ouch. That web-page needs some text formatting.
    – Nailer
    Apr 24, 2012 at 14:39

do you use them?

Yes, experienced programmers definitely do. You can avoid using most design patterns (excluding simple singleton stuff) for now; but the more you program and the more complex systems you build, the more you will feel the need to use design patterns. If you still avoid it, you will begin to feel the pain when you have to expand your system and change it as per new requirements.

If somewhere in the web I find a way to solve my problem, is this a design pattern?

Not necessarily. A design pattern refers to a specific way to design classes, their behaviours and interactions to achieve a specific goal (or avoid a specific problem). What you may have come across may not really be a design problem but a specific sequence of steps to program a certain API. For example: there is a certain sequence to establishing a socket connection. Do it wrong and your socket wont communicate. That sequence of steps does not constitute a pattern.

do you (programmers) find yourself looking for patterns

Yes. Design patterns embody the "prevention is better than cure" axiom. If you can spot a particular upcoming design problem beforehand, you can prevent massive redesigns to accommodate changes later. So it pays to know design patterns beforehand and look for places where you need to use them as you build your application.

where am I supposed to look btw?

Since you are a student you have probably not seen the typical problems that inspire design patterns. I strongly recommend that you look at Head First Design Patterns. They first present a design problem and then show how a particular pattern can solve/avoid it.


Design Patterns were not taught when I was in school. And, for most of my programming career, I've worked with legacy, non-object oriented code. In recent years, I've tried to learn them because they sound like such a good idea. However, I must confess that every time I've ever picked up a book or tried to read a tutorial on the subject, my eyes have glazed over and I've not really learned anything practical about them at all.

I can't believe I just admitted that in public. I think I've probably just lost any geek cred I may have established over the years.


Don't look for trendiness

Any standard programming solution to a certain problem can be considered a design pattern, it doesn't matter how popular they are, or if other programmers use them or not.

You might already be using a design pattern that hasn't been invented/specified yet.

Don't try using them, try thinking in their terms

The problem with design patterns is that sometimes programmers want to fit their problems into them when it is the other way around.

Remember design patterns' design convention have a typical problem to solve, you can even combine design patterns to tackle other bigger problems. This is kind of typical in Service-Oriented Architectures, just see some of the SOA patterns there are.

Look for them in the wild

There are plenty of open source projects where you will find applied design patterns. One example that comes to mind is Joomla: you will find singletons, observers. GUI libraries will have the decorator pattern, command pattern implemented, and maybe even flyweight.

There are other patterns such as data patterns, for example the Doctrine Project alone has used, the active record pattern (1.x), entity manager pattern(2.x), unit of work, repository, query object, metadata mapping, data mapping, and other more general ones like the strategy pattern, and decorator pattern.

There are just so many interesting solutions to choose. See Martin Fowler's Patterns of Enterprise Architecture, there are also data model patterns.

Just learn them for when the time comes

Learn them, know them, obsess over them and when the time comes you'll know how to solve programming problem x, you will be a better programmer already by that time.

Become an architect

I'd say that being able to think in pattern terms to solve problems, effectively turns you into a software architect. Even if you don't want to be a software architect per se, your solutions will have more technical quality, be cleaner and better scalability —in terms of design— by default.


I've programmed for about 7 years in C++ and learned patterns about 2 years ago. Most patterns probably have some applications, but in my usage, some are better than others. You have to think why you are using them.

The iterator pattern has actually made my code more confusing and has added unnecessary complexity. I can get the same maintainability using typedefs for STL vector types. And any changes I make to the class being iterated I also have to make to the iterator class.

The factory method, however, has been extremely useful, based on the polymorphism it provides. I forget who said it, but the statement "reusability means that old code can use new code", is definitely true with the factory pattern.

I've used the template method pattern for years without even knowing it was a "design pattern".

The Observer pattern has been helpful in some cases, sometimes not. You have to sometimes predict complexity to determine if the overhead complexity of the Observer pattern is worth it. We have a program that uses about 10 subscribers and there could be many more, so the observer/subscriber pattern has been helpful. Another program, however, has two GUI displays. I implemented the observer pattern for this program, and it has been largely unnecessary, simply because it added complexity and I don't anticipate adding more displays.

I think those who say to always use patterns assume that your program is going to be infinitely complex, but like with everything, there is a break-even point in terms of complexity.


Adding to Lunivore. Id like to quote this from the head first book

        ## **Three steps to great software** ##     
  • Make sure the software does what the customer wants
  • Apply good object-oriented principles
  • Strive for a maintainable, reusable design

It is during the third stage, after your system is working the way it is supposed to.Its time to apply the patterns to make your software ready for years to come.


Are they really used by the majority of programmers?

I would guess yes. In ADO.Net there is a DataAdapter class to give a simple example though depending on what area you want to specialize the patterns may vary.

Speaking of experience, I've had some troubles while programming, things I could not solve for a while, but google and some hours of research solved my problem. If somewhere in the web I find a way to solve my problem, is this a design pattern? Am I using it?

No, that isn't a design pattern to my mind. A design pattern tends to have some arrangement of classes and methods that define the recipe of a pattern.

I'd prefer to think of what you did there as a common practice. Beware of copy and paste coding though.

And also, do you (programmers) find yourself looking for patterns (where am I supposed to look btw?) when you start the development? If so, this is certainly a habit that I must start to embrace.

Sometimes as I see the same code over and over, I may find a way to refactor the code into a pattern or if I remember a solution to a similar problem involving a pattern I'll take it out and use it. Head First Design Patterns has more than a few patterns in it while Refactoring would be a suggestion for coding practices that may lead one to find various patterns. If you want another possible starting point, look at Microsoft's Patterns and Practices.


Learning patterns is not just learning something. You learn what you can do with programming languages. I for myself learned a lot about object-oriented programming just by learning how a pattern works (the composite pattern in this case).

As mentioned by Oded, most programmers use them sometimes without even recognizing it. The beauty of patterns is that you can adress specific problems with a predefined pattern so you don't have to think a lot about architectual things.


You will learn patterns as you start working with existing projects. There are so many patterns out there for you to learn, and it is not worth the time to master all of them as it depends on what project you are working on. Whenever you run into one, learn about it to see how it is used.

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