Any suggestions for a crash course on design patterns?

Question

I am going to be giving developers at my company a crash course on design patterns (after coming across some scary code recently).

One of the most important things I want to put across is that they save time in both the long and short term (which they really do!) - as developers here are put under quite a bit of time strain. All in all I need to demonstrate the every day benefits - things that will let them go home early.

Telling them that it might mean less bugs probably isn't going to hit home. I need stuff that is going to sink in.

I will probably do three to four sessions of an hour each. Do you guys have any suggestions on what to touch on/to do?

Answer 1

Head First Design Patterns would be a great place to start. It covers the mainstream design patterns.

Refactoring to Patterns might also be of interest.

If you can't buy a book for every developer, buy a few and spread them around.

Answer 2

Patterns are hard to learn first. I read the GoF book so often back then. Every year another pattern sunk into my head. So my only advice is that you pick a maximum of two patterns and go into many examples what to solve with it.

A composite is something that everybody knows. On this you can explain that it might be important to know that it has name that you can use and communicate. Important in patterns is that it makes it easy for others to recognize your intentions. And this little names are quite helpful.

I personally find the template mehtod pattern really good to deal with in OO based development. It is so close to how OOP should happen that it might have the benefit of improving coding style as well.

Answer 3

The approach most books take to explaining patterns is the exact opposite of what I'd like to see. They take a pattern, describe preconditions and what not and then give you an example. I'd much rather take concrete problems, and discuss alternatives. The one that stands out, that'll be the 'pattern' -- introduce it as such only then.

Choose patterns that are a) easy and b) most likely to be used in your code. Singletons are easy to learn (since they do not involve subjects/objects). Another interesting one is the observer pattern.

Answer 4

You are in a unique position for a course-giver: you know the developers and you know the code that they are working with.

A possible approach would be to look at some of the scary code, and go along the lines of "How could we go about improving this? As it happens, there's a design pattern called Observer...."

This might end up being a mix of design patterns and refactoring. But that might be appropriate, given that you're trying to reach developers working on an existing code base.

Answer 5

Try Wikipedia

Answer 6

The problem with learning patterns is you have to have enough experience with software to have seen the pattern (normally unnamed) in the code your written or maintained. If you've never written an observer, reading the description of the pattern will not be easy to grok.

I'm not saying you should not read about patterns. But be aware that one's ability to appreciate patterns is limited by one's inexperience.

The other problem with patterns, and the problem you will have, is they don't exist. At least they exist even less that "software" exists. Patterns are ideas and concepts. They are not runnable code. Runnable code can implement a pattern but the reverse doesn't exist. You can't just type "singleton" into your code and suddenly a singleton exists. There is no language where adding a "visitor" attribute suddenly makes all the glue to implement the visitor pattern. There are best practices and examples of patterns in various languages but they are not something you can stick in a library and just call.

So what you really want to do is teach some best practices where the core of those practices involves recognizing and using patterns. Being observant is a very difficult skill to teach (for all forms of observation).

The third problem with patterns is they aren't really the domain of coders. They are formally called design patterns for a reason. They are most properly a design time construct. Sure you can use patterns to help refactor existing code. But by and large, design patterns are jargon to simplify design discussion. This is again why there aren't any singleton code libraries. Using a singleton is an approach to code, not code itself.

All that said, trying to educate your programmers about design patterns can't hurt. Getting programmers to think is a good thing and if only one of them comes away from it with more than a surface understanding of patterns, you probably come out ahead of the game. Good luck.

Answer 7

Have a look at this site: http://www.dofactory.com/Patterns/Patterns.aspx It focuses on the many types of creational, structural and behavioral patterns and gives examples with structural,real-world and .net optimized code. Hope this helps

Answer 8

Good opening slides for any education course in my opinion are:
1) Why are we here? (Where has the need for this course been identified?)
2) What do I expect to learn?
3) Who should take this course? (What are the intended students, prerequisites, etc?)
4) When can I apply what I’ve learned?
5) Expectations of you (Participation, homework, tests, minimum classes to attend, etc)

For design patterns I could expect several visual tools or "job aids".

I would follow a structure similar to the Elements of Reusable Object-Oriented Software book:

1) UML – Class Diagram Overview
2) OOP – Abstraction, Encapsulation, Polymorphism, Inheritance
3) Cohesion and Coupling
4) What is a design Pattern? – Pattern Name, The Problem, The solution, The consequences
5) Why are design patterns so hard to learn?
6) Why use design Patterns?
7) How to Select a Design Pattern
8) How to Use a Design Pattern
9) Cover various GoF design patterns with examples – Show examples of code before applying a design pattern, and how it looks after like Vince Huston does in his examples.
10) Conclusion

As already mentioned, design patterns are really ideas, so when teaching you must convey the idea. If they understand the problem, solution and consequences of the design pattern, then they will be far better off than trying to force patterns into the code (and that will become a nightmare). Recognition of where and what patterns (if any) can be applied is the real goal. The Huston examples are really good for putting out an example of code to the class and seeing if they can identify a pattern to improve it. Hope this helps.