[via Darrell Norton]

Good post by on Darrell Norton’s blog about design patterns and refactoring.  I couldn’t agree more about his comment on Joshua Kerievsky’s book Refactoring to Patterns.  I’m a little over halfway through this book and find it to be THE missing link (at least for me) on understanding refactoring & design patterns.  The only problem: I want to have Martin Fowler’s Refactoring and the GoF’s Design Patterns on my desk at the same time!  Pretty tough when you keep just one of them in your bag to and from work.

Yet another reason for you to subscribe to Darrell’s blog.  Hope I run into him at TechEd 2005 in Orlando!

Bill Venners just posted Part 1 of an interview with Erich Gamma called How to Use Design Patterns. So why should developers learn patterns?

"I think patterns as a whole can help people learn object-oriented thinking: how you can leverage polymorphism, design for composition, delegation, balance responsibilities, and provide pluggable behavior. Patterns go beyond applying objects to some graphical shape example, with a shape class hierarchy and some polymorphic draw method. You really learn about polymorphism when you've understood the patterns. So patterns are good for learning OO and design in general."

Learning about patterns is also learning about Object Orientation, since patterns are OO applied to certain types of problems. Erich really liked the Head First Design Patterns book as a resource for learning patterns.

Developers just starting to learn design patterns often suffer from design pattern-itis, that is, they think "I need a new object, so I'll use an Abstract Factory." But don't start your application with patterns:

"Do not start immediately throwing patterns into a design, but use them as you go and understand more of the problem. Because of this I really like to use patterns after the fact, refactoring to patterns."

That is why Joshua Kerievsky's book Refactoring to Patterns is such a crucial book. (I haven't studied it extensively yet, but I've read parts of it and it's excellent.) Not starting with patterns allows the architecture to emerge around an application's abstractions:

"That's something you can often observe in mature designs. There are some key abstractions you often see as a design center, and around those key abstractions you want to achieve various things. So you see patterns growing out of such a center."