What are some techniques to teach programmers design patterns?

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?

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.

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 java.io.InputStream/OutputStream? 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.

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

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.

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.

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

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.

Ideas:

• 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.

Implementation:

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

    public void DoProcess()
    {
        this.Step1();
        this.Step2();
    }
}

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.

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.

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