Learning Design Patterns24 Mar 2012
Design Patterns are design solutions to recurring problems. The architect Christopher Alexander introduced this notion in his book “A Pattern Language”. He introduces patterns that range from the design of whole cities to the organization of single rooms. Here’s how he defines the pattern of a “street cafe” (taken from Wikipedia):
"The street cafe provides a unique setting, special to cities: a place where people can sit lazily, legitimately, be on view, and watch the world go by... Encourage local cafes to spring up in each neighborhood. Make them intimate places, with several rooms, open to a busy path, where people can sit with coffee or a drink and watch the world go by. Build the front of the cafe so that a set of tables stretch out of the cafe, right into the street."
The notion never really took off in architecture. Only Alexander himself and some experimental architects employed them in their projects. In the software engineering scene the concept was widely successful and the “gang of four” (Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides) collected 23 patterns in their book “Design Patterns: Elements of Reusable Object-Oriented Software”. The book was highly successful and influenced the software design of many object-oriented software libraries and frameworks and even programming languages themselves (think iterator).
Like any trend that comes up in the fast-moving scene of software development, it has many ardent supporters and equally many burning opponents. Its critics claim that it’s just another buzz word with no real content like many other trends invented by marketing departments. More to the point they claim, that it gives many people a false sense of security when designing a complex software system. Instead of solving real design problems it allows a software engineer to hide behind vocabulary that only gives the illusion of real understanding.
It’s hard to refute a criticism on this basic level, but you can see the advantages of patterns in their overall properties. Flexibility, loose coupling, encapsulation, ease of change with new requirements are just some of them. For me design patterns are just one more tool, that we can use when designing software. Like with any tool there’s a time to use it and a time to just “keep it simple, stupid” and go with the straightforward solution. There’s a great article by Colin MacDonald, that tells a compelling story about a young programmer, that is a little to eager to use all the tools.
I just recently finished learning design patterns in a more structured way by reading “Head First Design Patterns” by Elisabeth & Eric Freeman, Bert Bates, Kathy Sierra and Elisabeth Robson. The book manages to convey the intention of the most used original design patterns in a way that is easier to digest than the dry dictionary style used in the on design patterns by the gang of four. The Head First book is on top of many of the Top 10 book any programmer should read, but the book’s comic and verbose style takes some getting used to. At first I was most appalled how often they use Comic Sans, but I assure you that the content is good and it’s unique style manages to ease the study of these rather dry concepts. Jeff Atwood critiques the book in a nice rant, but I find it a little bit too opinionated to be taken much more seriously than a trolling attempt.