Design Patterns Are Not Good Programming
This is something that’s been getting to me, lately. The worst form of it is the almost religious devotion to model-view-controller (MVC), but in general, I think design patterns are an idea that people are largely taking the wrong way.
By way of an explanation, consider a zen koan. It’s relationship to zen is very, very much like the relationship of design patterns to good programming. A koan is not zen. It does not describe a zen state, but, if one looks at it properly, one can (un?)learn something about zen. Memorizing a million koans will not bring one any closer to zen than memorizing one. Doing as the characters in zen koans do does not bring one any closer to achieving zen. Making a practice of kicking things over when you’re asked to describe them is probably not as appropriate as it was for Joshu’s cook. There is something to be figured out in the koan, and once one understands it, the koan should be thrown away. It is a linguistic container for the idea; the idea itself is necessarily more elegant and more compact.
Similarly, knowing lots of design patterns isn’t going to really make one a better programmer. Using design patterns will probably result in better code, but it won’t, by itself, make one a better programmer. Unlike zen, good programming can be described quickly and succinctly: getting the most good code with the least effort.
For example, the concept of MVC can be applied to a web service. There’s a model for the data, a controller to do stuff with it, and a view that decodes method calls and encodes responses. Let’s say that it’s an XML-RPC service: all the view does is convert back and forth between XML and locally usable data structures (assuming the controller validates its input properly). Significantly, these structures are passed directly to controller, and what the controller returns is probably encoded and sent right out. There is nothing significant happening here. The view is extraneous. In turbogears, for example, one could use the CherryPy to do the conversion; I believe the whole process is no longer than four lines. Even in something as primitive as C or PHP, the view for the whole application, regardless of size, can be implemented in one function. There’s no point in setting up a sacred View pedestal to put it on.
The lesson to take away from MVC is that by breaking a certain class of application into these three components, it becomes easier to modify any of the components without needing to change the others. It prevents rewriting and saves effort, and less effort is better programming. Once this lesson is learned, MVC as a strict thing can be thrown away, and the idea of compartmentalization that it provides can be applied in some form where appropriate.
The same applies to other patterns: they are ways of approaching specific classes of problems. Although some of them are damn clever (think: visitor pattern), one will almost never run into a problem where the pattern, taken verbatim, is the best way to solve it. What they are is programmer-koans that provide insight into the nature of the problem at hand, and the nature of good programming. Design patterns are not good programming.
September 24th, 2007 at 7:59 pm
It’s actually worse than that, because MVC defined a solution to a problem that no longer exists. We aren’t responding to hardware events, and putting those events together into meaningful chunks anymore — all that’s been abstracted away from us by very useful libraries. So modern MVC apps aren’t very MVC at all, and that goes double for web apps.
On the other hand, there is still some use in breaking things up into three components for most web apps. Data models are complex beasts, and they shouldn’t generally be muddied up with logic to determine what user ations mean, and which templates should be used to send data back to the user.
So the general three parts, that were defined in the original MVC architecture, still make sense for a lot of web apps, though the three parts serve very different purposes, and interact with each other in different ways than they did in classic MVC.
When writing the TurboGears book I was faced with the problem of either fighting the new use of MVC terminology, or trying to explain how it’s been redefined, and what it means now. And ultimately I decided that educating people from withing their current terminological framework was a smarter approach than trying to rip the words out from under my readers.
Hopefully the approach was successful, but I still wonder if it was the right way to go, for many of the reasons you mention here.
October 6th, 2007 at 2:13 pm
I was intersted in reading more about design patterns after reading this post; I’d heard of them, but hadn’t actually ever had any exposure to them. I ran across a “free” *ahem* copy of Design Patterns Explained (2nd ed, Shalloway and Trott), and have since bought the book (and the Gang of Four text, which is next on my “work” reading list). It is interesting to read how the software patterns movement is linked back to Alexander’s architectural design patterns (I have a copy of A Pattern Language somewhere in storage, a must-read before I ever design a house).
Anyway, I was curious if design patterns were really as rigid as you’ve stated in this blog, or if it’s simply people misapplying the principles. Reading Design Patterns Explained has left me hope that it is the latter.
To quote page 265:
“It is also important to remember that the patterns are discoveries, not inventions. The pattern that is ‘right’ for your problem is /in/ the problem, not something to be imposed upon it. The specific way a patterns should be implemented, similarly, should be dictated by the nature of the problem, its constraints, requirements, etc., not based on an implementation you happened to have run across in a patterns book.”
If nothing else, the general OOD analysis techniques espoused in this particular volume seem useful regardless of the existence of “patterns”.
October 6th, 2007 at 8:00 pm
In the case of Turbogears, the MVC distinction is actually implied in the source layout provided. For large scale web sites which actually interact with users, this is actually an extremely functional idea.
Usually the use of design patterns is not terribly strict, and I suspect that with some messing around one could probably readjust the structure without an unreasonable amount of effort, but I haven’t attempted it.
The other thing to remember is that a lot of “programmers” out there maybe aren’t so good, and imposing a rigid, well documented architecture on them is one effective way of compensating for that fact. In these cases the goal of “good programming” goes partially out the window, and we settle for “getting it functional in something reasonably resembling the budget.” I know a couple of software engineering leads that I’ve talked to who were quite religious about their paradigms, usually MVC and agile development. They didn’t sound like confident programmers so much as acolytes who’d been handed something from the heavens that, when attended with proper devotion, would make their lives easier.