I agree with much of Jeff Atwood’s writing when it comes to programming and development. I’d say on any given subject 90% to damn near 100% (congrats to him on his new adventure). But I think his post on design patterns, unfortunately, falls into a line of argument that I disagree with strongly – that *identifying* design patterns leads to complexity. Complexity because some engineers leverage them right from the get go without thinking about simplicity first. He even flags Head First Design Patterns as a potential complexity creator.
I understand the concern. Every once and a while you get into an argument with someone who is telling you your code stinks because it doesn’t employ pattern “so-and-so” and every once and a while you come across some needlessly complicated code because the developer thought pattern “xyz” was the appropriate solution and implemented it without thinking a few minutes more about the problem and putting together something far simpler.
Replace the word “pattern” in the above sentence with “technology” or “API” or “archetecture”.
Give it a try. It leads to the same place. And I’d say the problem doesn’t start with patterns (or technologies, or APIs, or whatever). It starts with the developer.
Does that developer start from a KISS viewpoint, or one enamored by buzzwords?
So Jake Says: Music and Design Patterns:
Chord progressions are design patterns. They give a common framework musicians can use to communicate. However, the implementation is left to the musician. You can play classically or bluesy. You can shred the progression. You can take the most “outside” ideas of modern atonal theory and apply them to the song. There are elegant implementations, there are common implementations, there are “outside” implementations, and there are bad implementations.
Chord changes aren’t represented in the core notation/language of the music, but you can use musical notation to spell out changes. You can also use shorthand languages to design the music. The sentence “12-bar in Bb, 2-5-1 turnaround, on my lead” gives away none of the implementation details (voicings/melodies, etc.,) yet the song is written in a breath.
Design patterns act the exact same way for programmers. They are, at heart, a common framework by which programmers can discuss a design. They can spend less time focusing on minutiae and more time discussing design and code.
Even if you are using Python or Perl and you don’t have to explicitly define an Iterator to loop through arbitrary collections, you could easily point to a “for x in y” statement and say “iterate through y” to describe part of an algorithm. You will be correct, and a coder from any paradigm won’t have to give it two thoughts.
Design patterns always exist, but are sometimes invisible.
