Seeing the pattern – or not

My late roommate from Stanford, John Vlissides (he passed away much too early), went on to co-author a book Design Patterns: Elements of Reusable Object-Oriented Software that has had quite an impact on the software development community. According to Wikipedia it was in its 39th printing in 2011.

I read the book a long time ago, probably around the time it came out and haven’t had a very good reason to revisit it since. Mostly because I don’t really do software development anymore except as a hobby. Also, I believe somebody actually “borrowed” my copy. My last project (media player) was rather straightforward regarding design patterns. There were “input pins”, “output pins” and “filters”. (The tricky parts were the real-time aspect and the multitude of threads.)

Design patterns

This new hobby project, based on Eclipse, is something totally different. It is soaked in design patters. It uses “adapters”, “decorators”, “factories”, “commands”, pretty much the whole index of the DP book. I just realized that the reason why I have such a hard time understanding the code is because I don’t know the design patterns.

See the pattern? (The rider is my daughter and the horse is my horse Brim Time.)

This is quite similar to an other problem of mine from a totally different domain: remembering a show jumping course. I’m learning jumping with my horse. My daughter, who has been riding and jumping for much longer than I have, only needs to look at a course briefly to remember it. She can figure out the order of the fences even without seeing the numbers because she has seen a large enough number of courses to know what they usually look like; she knows the patterns that are used in constructing a show jumping course.

Patterns everywhere

The concept of a design pattern can be applied to a wide spectrum of domains. Software design patterns [2] have been compared to architectural design patterns [1]. Other design patterns that I come to think of (now that I’m at it) include:

  • Western democracy and its institutions.
  • A supermarket.
  • Traffic with its rules. The informal patterns vary somewhat from country to country which makes it somewhat perilous to negotiate the first few kilometers from the airport in a foreign country in an unfamiliar car.
  • The weather.
  • The interactions in the imperial court of Ming dynasty China.
  • A matrix organization.

The list of course goes on indefinitely. Patterns are so ubiquitous that it feels almost trivial to talk about them but the fact that we know how to behave in a supermarket without thinking of it highlights how useful and important patterns are.

I went ahead and bought a Kindle-copy of DP. One advantage with e-books that I haven’t thought of before is that an e-book is almost impossible to lose by lending it to somebody (I don’t even know how to lend it).

Links

[1] Patterns in architecture.
[2] Patterns in software.

Related Post

Leave a Reply

Your email address will not be published. Required fields are marked *