In Defense of Design Patterns

October 6, 2009

It’s fashionable to bash software design patterns. “The Singleton Pattern? You mean, a global variable? Hahaha!” It’s hilarious. But I’ve noticed that those who mock are also, curiously, those who’ve not learned about them. I think they (the patterns) serve a useful purpose.

My analogy is to data structures. Imagine that we didn’t have names for data structures, and you had to repeatedly say, “Let’s put data in objects where each object has a reference to the next object, and the last reference is null, and we keep track of only the first one.” It’d be hard to communicate. There’s a bunch of information in your head associated with the name linked list and without the term you wouldn’t be able to organize it or communicate effectively about it.

Design patterns are just that: names for common ways of organizing code, so instead of saying, “Let’s make a class that you can configure and then ask it to atomically make another object so that the other object doesn’t need a long constructor or ever be in a half-constructed state,” you can just say, “Let’s use the Builder Pattern.” Along with the name comes a shared understanding of how and when to implement it, advantages and drawbacks, and what to call the class.

People often crack open a pattern book and say, “There’s nothing new here!” That’s the point. It’s for code structures that we’ve been using for a long time but never had a name for. In fact, seen that way, it’s a bit ridiculous to bash design patterns. Why wouldn’t you want to name a commonly-used thing?