Neil's News

Design Patterns

18 September 2006

Those of you who aren't programmers can skip this post and proceed directly to the cute animals.

The rest of you are probably familiar with design patterns. This weekend I inhaled the book (it's well written) and groked everything from Abstract Factory to Visitor. There's no question that all the patterns are useful. But I was struck by the fact that I'd already used 90% of them one or more times. They seem like plain old common sense. The question I was left with was whether there are benefits to studying software design patterns.

Probably the strongest argument for design patterns is communication. If we've both read the book, I can talk to you about using "a facade". This is shorter than having to say "an object that provides one high-level interface for a group of low-level objects". However, this cannot be the sole justification since that would make the existence of design patterns purely recursive. No other field of study (outside of Theology) consists solely of self-instantiating terminology.

Another commonly cited argument for design patterns is that although they are common sense to experienced programmers, novice programmers can learn from them. I don't buy this argument. It's like teaching someone how to use MS Word by handing them cue cards with step by step instructions for various operations. "To print, click File, then click Print, then press Ok." Formulaic instructions often get jobs done, but in my experience they teach nothing -- other than dependence on formulaic instructions. One has to explore and think.

"Physics Envy" may be another reason for their popularity amongst computer scientists. Programming is still an art form, there's immense pressure to turn it into a science. But design patterns make poor science. There's no criteria for determining what is or isn't a design pattern. There's no method for discovering new ones. There's no predictive power that they imbue.

Maybe design patterns are a work in progress. The 23 patterns listed in the above book may just be the tip of the iceberg. Deeper patterns yet to be published may be clever and not intuitively obvious.

What are your experiences with design patterns? Have they actually helped you or not?

Quadir writes:

Design patterns help because they:
- Provide a solid approach to solving a problem (that could have infinite solutions), tried, tested, true
- Because the programmer and the tool set provider know the design patterns, a library can include pre-implemented or skeleton classes/interfaces to inherit/implement maximizing re-use. Adapting to someone else's class that also uses the same design pattern is often very easy.
- When reading the code to a class, knowing what design patterns it implements instantly tells you what pieces you should expect to see in the code, and a function that may have seemed out of place now makes sense. This is huge for maintainability by multiple programmers, say in open source. Also relates how a programmer should interact with the class, or use it to interact with other classes.

Maxamillian writes:

I think you pretty much sum up my views on the topic, although I do think that their providing a way of talking about certain techniques is actually quite useful, and I think that probably all but the top 10-20% of programmers *would* benefit from studying the patterns.

I'd also note that Design Patterns is very OO-centric, and that functional programmers (a) probably find the primitive nature of many patterns to be laughably-amusing attempts to code around deficiencies in non-functional languages and (b) probably *do* have a lot of more interesting, less-obvious patterns.

< Previous | Next >