Design Patterns

17 February 2012

I’ve been doing a lot of application programming over the last eight months and it’s given me a new perspective on the use of Design Patterns in software.

Rather than “a general reusable solution to a commonly occurring problem”, I currently think of design patterns as a shared vocabulary for discussing the observable commonalities between two or more solutions, after they’ve emerged.¹

While the shared vocabulary of design patterns might be useful for discussing something that’s already been done, I don’t find it helpful before or during programming.

I’ve noticed that when we discuss patterns before or during programming – especially pair-programming – it leads the tests and code down a route that they may not have naturally taken if we just focused on the desired behaviour, or the capability, that we’re trying to enable in the system.

Starting with a solution often encourages us to build things that only exist to serve the pattern; a sort of micro-scale YAGNI.

Of equal concern; the finished code tends to communicate more about the design pattern, than about our problem domain. When we return to maintain the code, we spend time identifying and discussing the pattern and reverse-engineering an imperfect understanding of our original intent.