Jeff Atwood's Coding Horror blog is among all other software development-related blogs the one I keep the Unread count at 0. This chap simply amazes me with his near-daily rate of new thoughts and insights on matters concerning the computing field at large. I cannot imagine how much time I'd have to spend in order to accumulate a fraction of his knowledge and understanding - well enough before committing to laying down informed opinions. Does he really have a job?
Anyway, earlier this month he wrote a recommendation to get developers to reconsider how they perceive and approach Design Patterns. While most of the stuff he writes about is undeniably eye-opening for me, this is not one of them.
Coding Horror: Rethinking Design Patterns:
Jeff Atwood presents the idea that design patterns have a tendency to make a solution more complicated and complex than it needs to be. While I can understand his angle about over-enthusiastic developers who want to implement patterns for the sake and thrill of implementing them, I have a somewhat different perception to the issue of using design patterns. Design patterns exist because they have been used, with pretty good success, to solve a particular problem encountering when face with the challenging of implementing an effect/function in the system. These problems are usually not straight-forward and easy to solve. The complexity of the problem in itself usually dictates some complex the utlimate solution will be. (I state "usually" because there are those shining times when something terribly complicated gets solved in a mind-blowingly simple manner.)
Design patterns in my understanding is about finding the simplest, most elegant way to tackle a problem. By establishing a common volcabulary and understanding of its concept, development teams can deal with them quickly and move on to handling more business/domain-oriented problems. In my experience, the lack of design pattern use resulted in monolithic, inextensible, brittle, defective implementations that is complicated and unwieldy. Both to the user and developer. I do not know how many times I saw parts of a system and went, "ouch, if so-and-so pattern was implemented here, how much simpler it would have been!"
If a system's design is getting more complicated soley because of a design pattern, then yes it is time to find that simpler design pattern that can do the job equally well. Otherwise, a free-form solution to the problem probably is going to be much more hair-tearingly complex.
Jeff's second point seems to imply that the language/platform either has to be perfect, or it is fundamentally broken. I do not think there is any programming language or API in the world that is totally devoid of any need to apply some design pattern knowledge. Every platform has its own ways of doing and accomplishing things, and its own shortcomings. Some design patterns get formulated precisely to overcome those shortcomings. Again, which probably gets overcome by ugly means without seeking a design pattern, which aims (does not mean it always achieves) to be the simplest solution. Are we able to agree there is a language existing that has no "fundamental" flaws, having no recurring design problems?
Also, some design patterns are nothing about the platform or language, and more about how certain domain/business rule may be met. Even taking a lower-level example, like arbitrary user authorization - is that something that should be baked into the language? I find his second point rather sweeping and without good scope.
Let us not be mistaken here. There is a time to use a spoon. There is a time to use a knife, a fork. Or chopsticks. Let us know what problem each was designed to solve, and how they function to achieve. And use the right tool for the right situation. Or should we just think of situations where, "there is no spoon...."