Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I'm in a position where my developers are asking to learn design patterns. So far we have done a book club reading Heads First Design Patterns. During this we worked through examples and talked about how to apply this to areas of our own products. The problem is that these exercises didn't stick and they continue to ask to learn them.

This post has some great example of books we could use, but I'm also looking for techniques on how to teach the information.

So what have you done to teach other developers design patterns?

share|improve this question

closed as too broad by MichaelT, GlenH7, mattnz, Corbin March, World Engineer Sep 11 '13 at 22:26

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

Head First design patterns has got to be the best resource I have for DP. It's designed to stick. If that isn't working the primary question is why? I am at a loss as to how that book fails to teach except for a lack of effort. Or, possibly a need to learn more about fundamental OO, which Head First also has a remedy in their OO book. – P.Brian.Mackey Jan 9 '12 at 22:39
A good question, unfortunately its too broad and not suited for this type of Q and A site. – mattnz Sep 10 '13 at 23:00

11 Answers 11

up vote 4 down vote accepted

Practice, Practice and Practice some more. The more you use them, the more they will stick! Works for me. Reading alone will not be enough! (At least it is not for me.)

Doesn't have to be a work example either! Where I work we run Coding Dojos on lunch-times (with free lunch) for things like this.

share|improve this answer
Ah Coding Dojo's, that seems like the best of both worlds. They have to do little preparation in order to attend and participate. Are you aware of any resources that have an outline or script to do this? – Brian Dishaw Jan 9 '12 at 16:36
@BrianDishaw - might be worth a look. With ours we set a small problem and begin it in the Dojo often we don't get finished so we carry it on in our own time or at the next Dojo. The purpose of the Dojo is to start the problem and discuss possible solutions, but the key is focus on technique rather than just solving the problem. Ideally, you want a problem that can be solved in 90mins or so. – Scott Sellers Jan 9 '12 at 18:31
Mmmm... cold delivery pizza. This is a great technique when the team and management buy into it. – jfrankcarr Jan 9 '12 at 19:02

Book club reading done. An easy to access book shelf that has books on design patterns, software engineering, programming languages and related subjects would be the best thing I'd want if I was in your team. If I keep asking for more, and I have a book shelf to hit most of the times, I will be just as happy.

It did not stick the first time? I believe it is just fine. Everybody fails the first time. No?

share|improve this answer
how does this answer the question asked? – gnat Sep 13 '13 at 7:12

Through actual use cases. And by this I mean real situations where they DO help, and DO improve clarity, and they DO improve maintainability, and where they DO improve the design.

Studying from books because you have to, causes two problems. Wannabe superstars will put those patterns everywhere, therefore creating code goo, and a lot of people will not understand what they read because they don't use this in practice. So it's not effective if it's done like a certification thing.

But software architect should know them, and try to feed them to others by describing the big picture and why it should be done this way, what are the benefits, and what are the drawbacks.

share|improve this answer

I've studied design patterns several times. I read the book, studied with coworkers, and even attended a study session. I think each time I learned more and more depth to the patterns. I think design patterns are something you can revisit many times over and learn new insights and connections between the patterns. Once you start to see similarities in structure between the patterns (say the similar structure between state and strategy pattern or the difference between decorator and strategy) you'll have reached a new level in understanding them.

If people still want to learn more about them. I'd start again and look for opportunities to do coding exercises around them. Or compare and contrast two patterns. Try solving a common problem using two different patterns (strategy, decorator, and template method are good ones to do this type of exercise with). Look for examples in Frameworks that use patterns (What pattern is How about javax.swing.Border what pattern is that?) Or look at other languages and how patterns might be implemented in them (Ruby's .each or .inject method is what pattern?) Then try and explain why the author used that pattern instead of something else.

I also over used them and royally screwed up some software using them. You are going to go too far with them. Abuse patterns and you can easily undo a lot of readability. I think its unavoidable and part of the learning process with patterns. As most developers get so enthralled with the flexibility they give adding unneeded flexibility is too tempting for most. That's not to say design patterns are pointless or without merit, but I think I learned the most about them when I backed away from using them for everything. I still use patterns, but with more wisdom. Refactoring to patterns is typically the best choice.

Which is another avenue you could look into. Martin Fowler's book on Refactoring applies design patterns to simplify and make code more extensible. You could introduce refactoring techniques while also learning how to best patterns.

share|improve this answer
I like your suggestion to use refactoring as another avenue to work on design patterns! I hadn't considered that approach but it make a lot of sense the more I think about it. – Brian Dishaw Jan 10 '12 at 2:01

Most patterns, specifically the GoF patterns, feel really forced and not that useful unless you're really grokking SOLID and the concept of writing loosely-coupled code against interfaces instead of implementations. However, once you've got those concepts down, patterns are much easier to see as a language used to identify constructs that often naturally emerge (as it's supposed to be), as opposed to concepts that need to be learned and forced into someone's code.

For this reason, I recommend studying dependency injection before trying to understanding patterns. You'll even end up learning/teaching the most important patterns as you go - for example, Abstract Factory goes from being an odd idea that kind of looks like it solves a problem that doesn't exist to "oh, it's just the thing we provide to a class when it needs to create instances of something else at runtime."

share|improve this answer

At first, don't tell them anything about design patterns.

Have the students study a number of different object oriented GUI frameworks. If that's too much, divide the class into groups and have each group investigate a single framework and report back to the class. You might guide them with a list of questions that they should be able to answer, like:

  • Describe the process by which an application responds to user input.
  • What mechanisms does the framework provide for passing messages around in an application?
  • What is the overall structure of an application written using this framework?

The point is that GUI frameworks tend to use a large number of design patterns. If you get your students to look at several frameworks, they should start to notice commonalities between those frameworks. Those commonalities are design patterns. Once they see some of the patterns for themselves, they'll intuitively understand what a design pattern is and why it's helpful to know about them (or at least, that seems to be how most people come to really understand). After that, you can tell them the GOF names of the patterns they've recognized, and it should be easier to explain other patterns that they haven't yet noticed.

share|improve this answer

I discovered that the patterns that I understand best are the ones I "invented" for myself. I remember discovering my first pattern (the Template Method) when I went from 300+ lines of code to only 50+ lines after a tiny refactoring. It happened a whole year before I learned the official name of that pattern from the GOF book.

I think that my experience can be replicated in the book club-style settings. Start with a "homework" to come up with a design that can be addressed by a known pattern. Participants would either discover that pattern for themselves, or discover the problems that the pattern addresses. You could then walk them through a pattern-based solution in the book club meeting, pointing out the typical deficiencies of the alternative approaches. These who put a good-faith effort into doing their homework will know the concepts before the meeting, so instead of explaining the meaning of the concept with its corresponding nomenclature to them, you would be able to explain the naming of the concept that is already familiar to the participants.

share|improve this answer

The main thing to remember about design patterns is that they are not so much a design guideline as a language to be used for communicating design issues.

The important thing is not to apply design patterns to your software but to recognise an appropriate design pattern when designing (or re-factoring) parts of your system and use those design patterns to communicate to others what your intention is more clearly, then use this communication as the basis for further discussion of the design.

The other thing to do is look at your existing software and analyse it in terms of patterns. Identify different parts of the current design in terms of patterns and understand why your design was done in that way. You may well find both patterns and anti-patterns in your software by doing this sort of review and this could lead to future designs which don't have the problems that often come with such anti-patterns.

Eventually you will go into a design reviews and everyone will be comfortable when someone pipes up with "I think we need a facade here".

share|improve this answer

What you've done already is good. Sometimes it takes a few times to have something stick. If they ask again, teach it again. When it starts getting out of hand (asking over and over and over), then you have to consider the developers (lack of) coach-ability.


  • Beyond that, use real-world scenarios and implementations. When designing a new feature or bug fix, collaborate on the technical design spec of the feature. Basically, walk them through (and have them walk you through) the use of the pattern to solve the case.

  • Work with them and have them make their own, personalized, pattern catalog. For reference: You may already know this, but the GoF book is defined as a pattern catalog. Essentially, you write a UML diagram and the general problem that the pattern solves, with some code for the pattern.

So template method might look like:

Template Method

Problem: You have a process, or series of steps, that need to be performed, but now how they will be specifically implemented by multiple unknown objects.


public abstract class TemplateObject
    public abstract void Step1();
    public abstract void Step2();

    public void DoProcess()

public class ConcreteProcess : TemplateObject
    public override void Step1()
        /* code */

    public override void Step2()
        /* code */

You can then share this with the team (make a shared OneNote workbook or something, possibly with links to implementations in your company's product).

  • As others have said: practice, practice, practice. You can have problems that are handed out every monday - similar to coding katas - that require design patterns to implement. The winner (fastest, or best use of patterns, least overuse of patterns) gets to be PM for the day, or doesn't have to babysit the build for the day. Something like that.
share|improve this answer

I was on a team who learned design patterns as a group. Each of us took turns presenting the patterns and coming up with our own examples. Presenting these ideas is a great way to make learning things like this more active and fun. It also forces the presenter to dig a little deeper in their understanding.

Other things we did was to:

  • try and find places in our code where the pattern was implemented (sometimes without intention) or places where the code could be refactored to implement the pattern. Relating the patterns to the work we've actually done (and were doing) was really helpful.
  • examine how the patterns relate to one another and different ways to combine them.
share|improve this answer
I like this technique in general as it increases the ownership of those doing it. The hurdle is getting them to do it in the first place. A lot of developers fall into a stance where they tell you to choose to either "get stuff done" or do preparation for this activity. I find it hard to get people out of that mindset. – Brian Dishaw Jan 9 '12 at 16:37
I like this technique also. The best way to learn is to teach others. Even if you don't know the subject that well, it'll force you to dig deeper since you're trying to look at it from all angles to then teach it back to others. – QuanhD Jan 9 '12 at 16:45

Just keep using the terminology (where appropriate) and, when people are confused, tell them to Google it, or hand them a book.

After all, design patterns are merely a form of communication. You do not want to teach them in a way that says, "find reasons to use these, everywhere." You want to teach them in a way that says, "If I say 'use a Strategy for that' then you should know what that means, or know where to find out."

share|improve this answer
I found that post when we were choosing what book to read. I really like the notion that it's a communication tool primarily. – Brian Dishaw Jan 9 '12 at 16:34

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