A couple of weeks ago in a bit of frustration I asked the question “Why aren't design patterns common knowledge?” and received a lot of good comments.  One of the comments that stuck with me was a complaint about a lack of concrete examples.  I’m going to make an effort over the next month or so to make some posts with examples from my work.  In the meantime, here’s my advice for why and how to learn about design patterns. 

Of course, the first and last time that I conducted training on design patterns went badly, so read with caution.  On the second day of the event, with basically zero sleep, I presented for about four hours straight.  When I got an opportunity to turn the speaking over to my colleague, I rushed off to the restroom to catch a break.  As I was flushing the urinal, I noticed that I still had on my wireless microphone.  I wasn’t too concerned because I was surely too far away for the signal to carry.  When I snuck back into the conference room, my colleague looked at me and very loudly said “this is when we FLUSH the cache.”  That was the moment when I realized that consulting probably wasn’t for me.

Why Learn about Patterns?

• Thinking and learning about design patterns is a great way to learn the ins and outs of Object Oriented Programming.  If you’re not taking advantage of OO features in .Net or Java you’re missing out on a lot of the power of the languages.  Patterns are also very important for SOA as well.
• A former colleague of mine used to say that design patterns are “if/then” killers.  A lot of patterns shift variations to polymorphism.  That might not sound that important at first, but it can do wonders to improve the quality of code (readability, testability, removing duplication, extensibility, etc.).
• Patterns are often a design shortcut.  Design patterns are previously described solutions to reoccurring design problems.  There isn’t that much new under the sun.  Chances are somebody has faced a similar situation no matter what your design dilemma is.  Familiarity with design patterns can be a key to unlocking the accumulated design knowledge of many other software designers.  It’s kind of like how Optimus Prime had the “Autobot Matrix of Leadership” that held all the memories and knowledge of past leaders (or Mat Cauthon in the Wheel of Time for that matter).  Geek points if you understand any of the previous sentence.
• Patterns happen.  One of the comments on my previous blog post was that developers don’t learn about design patterns because they are never getting to do “greenfield” development and weren’t involved with the patterns used in the system.  That’s probably true for a lot of developers, but the patterns are still embedded in the system.  Recognizing the patterns in an existing system can aid in understanding the existing design.  Maintenance development is just as much software development as writing new applications.  It’s foolish the way we often denigrate maintenance coding.
• Communication.  Patterns give developers a shared shorthand terminology to discuss design choices.  When someone tells me that a method in an abstract class is a “Template Method,” that communicates a lot of information to me because I understand the intent of the pattern.  Even if I didn’t know the pattern, I could quietly google the pattern on my own and understand what my peer is talking about.  This benefit can be completely negated if the other developers are not familiar with the pattern in question.  If you’re a lead developer, you might invest some time into explaining any design pattern you’re using to the other developers to create a shared understanding.  I got into a heated discussion with a developer last year over my decision to use a composite pattern.  In the end it turned out his discomfort was largely due to the fact that he wasn’t familiar with the composite pattern.
• Because you might have to be interviewed for a position by me someday and I think they’re important[:)]
• Spouting off patterns can impress the weak-minded.

Erich Gamma, one of the “Gang of Four” gave an interview to Artima.com about how to use patterns.

How to Learn about Patterns

• Write code.  Do some sort of nontrivial, personal coding project where you can freely experiment with design patterns.  After reading the GoF book for the first time I started to apply some of the patterns to a DHTML reporting framework I was writing with Javascript (go ahead and laugh, but Javascript was and is more OO than VB6).  That was by far and away one of the smartest things I've ever done to learn about software development.  You almost have to do some sort of coding on your own to really learn how to be a developer.  Most of us just don't get enough development or design opportunities on the job to truly learn how to be a good developer.
• Discuss patterns with other developers.  I've been fortunate to work with some folks who were passionate about software design.  User groups in your community are a great place to talk shop and learn new things.
• Concentrate more on the motivation and impact of a design pattern on a design than the particulars of the implementation.  Knowing when and why to use a pattern is more valuable than knowing exactly how to code the pattern.  It’s always easy to look up the pattern implementation in whatever language you’re using when you decide that the pattern could be useful.
• Read up on design patterns.  I’ve listed a couple books below that I like, but try Google first.  The MS PatternShares site is also a good (free) start.

Recommended Reading

Here’s a list of the books I’ve read about patterns that I would recommend.  I actually don’t recommend the original “Gang of Four” book as your first read.  There are better, easier introductory sources now.  Do read the GoF book at some point (you can find it in public libraries).  If nothing else, you can’t call yourself a real developer until you have a copy very prominently displayed on your bookshelf.

• Applying UML and Patterns : An Introduction to Object-Oriented Analysis and Design and Iterative Development by Craig Larman.  In its third edition now, this book is my choice for the best introduction to Object Oriented Programming.  Larman’s GRASP patterns for assigning responsibilities to classes are a must read.  There is, or was, some specific verbiage on the Rational Unified Process.  You have my full permission to ignore these chapters.

• Patterns of Enterprise Application Architecture by Martin Fowler.  This book is absolutely outstanding and applicable almost every single day.
• Enterprise Integration Patterns : Designing, Building, and Deploying Messaging Solutions by Gregor Hohpe and Bobby Woolf.  I don’t *get* to do much SOA or integration in my current job, but I did quite a bit in a previous job.  I think this book does an outstanding job presenting a lot of the potential pitfalls and solutions for reliable messaging (yes Darrell, I know it’s a bit misnamed).  Asynchronous messaging is a completely different ballgame than writing OO code inside a single process space.  The EIP book is a great shortcut to learning the rules of the messaging game.
• Refactoring to Patterns by Joshua Kerievsky.  It can be dangerous to use a design pattern too soon.  Over-design slows down software development projects.   Instead of speculative usage of patterns, Joshua Kerievsky shows how to recognize opportunities to apply design patterns to existing code to improve the quality of the design.  I haven’t been able to finish this book yet because it keeps giving me ideas on how to improve my StructureMap code.
• I haven’t read the Head First Patterns book, but a lot of people are happy with it.

My next post will be a couple examples of using a Decorator pattern in code.