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

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.

Head First Design Patterns is an excellent reference as well.