Design Patterns, Aren't?

Returning from vacation, I saw that Jeff Atwood wrote a post on "rethinking design patterns" in which Jeff criticizes the GoF design patterns book.

Jeff says:

Design patterns are a form of complexity. As with all complexity, I'd rather see developers focus on simpler solutions before going straight to a complex recipe of design patterns.

If you find yourself frequently writing a bunch of boilerplate design pattern code to deal with a "recurring design problem", that's not good engineering -- it's a sign that your language is fundamentally broke.

I agree that these can be a problem with using design patterns in general and the GoF ones in particular. I would add that using design patterns just to be able to say you've used them is wrong too (this may sound obvious, but I have seen organizations where this was encouraged).

I don't think, however, any of those problems are problems with the patterns themselves. This is not to say that the GoF book is perfect. For instance, all the patterns don't stand the test of time. The most prominent example for that is the Singleton pattern, which I hardly recommend using these days. Singletons are problematic for testing and create a tight coupling for a specific instance. There are better ways to create a mono-instance if that's what you need (I think others have posted about it in the past but I can post about it separately if needed).

Also, newer languages sometimes provide better ways to tackle some of the design patterns solutions; see, for example, the recent post by Alex Miller where he talks about an alternative for Template Method. Not all the patterns are that useful (Flyweight comes to mind as an example).

Nevertheless, the GoF book is one of the most important books in computer science. First it is a seminal work which introduced the patterns thinking into software development. Today we have literally hundreds of patterns on all subjects and technologies. I think it is a very good think since the looking at a problem from a pattern perspective gives us more depth and understanding on both the problem and the solutions vs. other ways I've seen.

Even in itself, the GoF book is great, since many of the patterns are valuable and can help us solve real problems. We just need to keep in mind that the sample implementations in the book are just that -- samples. There can be more than one way to code a pattern and still gain the benefits (these are "design" patterns not "coding" patterns). A few weeks ago, someone asked a question on the Visitor pattern in one of the forums I monitor. The guy needed to add an additional parameter to the Visit method and asked if it wasn't a violation of the pattern. I told him that there isn't such a thing as "violating a design pattern". The patterns are a means to an end -- not some coding codex we should keep. If we treat the design patterns as pieces of knowledge rather then a holy script, they can really help avoid some stupid mistakes.

Thus, at the end of the day, I still think the Gof book is required reading for any new developer. But hey, that's just my two cents :)

Posted by Arnon Rotem-Gal-Oz at 05:43 PM  Permalink