Leading the Horse to the Fountain of Knowledge

Christopher Smith — Thu, 01 May 2008 22:48:00 -0700

While truly great rants are mostly entertaining, some rants can be enlightening for the insight they provide during rare moments of candor about things that aren’t obvious to those who don’t share the ranter’s paradigm. Such is the case with Design patterns are from hell!. I’ve seen a lot of critiques of Design Patterns, and I’ve seen a lot of misuse of Design Patterns, but I totally didn’t grok what the real problem was until reading this rant. Now I finally get it.

The killer insight that I was lacking was the notion that people reading the books would focus on the wrong thing. I was blinded by what I found to be very clear statements by the authors of the book about the benefits and purposes of patterns, how one should select patterns, how they differed from other reuse techniques, and indeed even the title itself. It seemed clear to me that it was all about design, all about practical solutions to common problems encountered in OO designs (and yes, the authors explicitly state that these solutions are nothing new, but rather well established), and most importantly: not about the code.

What the Design Patterns book teaches is for people to think in the box instead of outside of it; just as I did on that exam. Pattern thinking has now permeated and perverted peoples’ thinking to the extent where patterns are perceived as being an ends; something you need to use to correctly solve problems.

First, I don’t get how that principle related to “the Plank”, because it seems clear from the statement that he knew how to solve the problem using a different one of the cookie-cutter solutions he’d learned. Rushing to judgment before understanding a problem doesn’t strike me as “thinking in the box”. Normally, people “thinking in the box” spend most of their effort on careful consideration of how a problem resembles and differs from problems they’ve seen before, giving up if it is too different from anything they’ve worked with before. Secondly, he jumps from talking about “Design Patterns” the book to “Patterns” in general, apparently failing to recognize that Design Patterns was just one book detailing commonly encountered design techniques of OO developers and comes far short of representing all patterns (indeed, the PLoP books detail new patterns presented each year), they were just the low-lying fruit. Even if you forgo this misnomer, it somehow misses the very logical conclusion one should reach in not finding a pattern that fits your problem: your problem isn’t a commonly recurring one. It boggles the mind to think one would instead think to apply a pattern to a problem it was explicitly not designed for.

Now I understand why people gripe about the Singleton all the time: they’ve too often run in to developers who use it because they can, not because they need to, developers who think of the Singleton solution instead of the kinds of problems the pattern addresses.

Here’s the problem, if one is the sort of person who tries to figure out the minimal amount of studying to get through one’s statistics class (ironically applying approaches to achieving this that could have been derived from statistical principles ;-), one probably skimmed (or worse skipped) over the beginning of the book that takes the time to explains how to use the patterns. One probably went straight to the patterns themselves, and after looking at several of them, one probably decided the real meat of the patterns was in the code itself, because one’s main use for programming books was to look for code samples and apply them to your work without having to think so carefully to avoid making mistakes.

To paraphrase JWZ: now they have two problems.

Thinking in patterns is exactly the wrong thing to do! It makes you think in terms of the solution instead of in terms of the problem! Pattern thinking makes you try to fit a round, square, or oval hole (your choice of patterns) to the triangular peg (your problem). When all you have is a hammer…

A designer who goes around thinking about design in terms of trying to shove a bunch of pre-built solutions in to a problem is screwed whether they’ve read Design Patterns or not. A designer’s first focus should always be on what problems they have to solve, and only think about solutions as a consequence of addressing said problems. If you focus on the solutions instead, you will inevitably be wandering around with a hammer, thinking all the problems you face are pegs.

What was curious to me when first reading the quoted text above was that I thought it was odd to think of Patterns as solutions looking for a problem. The book quotes about the specific way that patterns are documented, and right there at the beginning of each pattern is talk about the kinds of problems the pattern is appropriate before. Heck, the pattern catalog was even grouped by the kinds of problems each pattern solved! It seemed obvious that the proper way to organize your thinking about patterns was in terms of the problems they solved (indeed, I’d often forget details of specific aspects of designs or implementation techniques for patterns I didn’t use much, but I tended to remember their applicability quite clearly). It’s odd to me that one would think one had to organize your thinking in terms of the solution, particularly since the solution was inevitably so much more complex than the problems it solved. What I was missing of course, was that to someone trying to find the “meat” of a pattern without reading and understanding the whole thing, they’d tend to of course focus on where the biggest sections of the pattern description were, and where the complexity was. So now you’ve compounded the problem: you’ve dramatically increased the cognitive load necessary to select appropriate patterns and you are focused on the wrong thing for coming up with a good design.

But wait, it gets worse!

For example, before dumb and dumber decided to call it the “visitor pattern” every programmer worth his salt would just call it a “map” operation (as in the LISP functions “map”, “mapcar”, “maplist”, etc). That’s just, oh, something like 1994-1960(?) = 34 years of previously established terminology! Twits.

Yup, he just completely missed that the visitor pattern is primarily about double dispatch, and even talks about how CLOS does this natively. It talks about how Smalltalk’s do: (the moral equivalent of map/mapcar/maplist) won’t get you double dispatch support. Most importantly, it even talks about how putting traversing behavior in the Visitor, as done in the sample code, only really makes sense if the logic for determining what to traverse depends on results of the algorithm itself (i.e. when map/mapcar/maplist won’t work).

So, by focusing on the code, rather than the discussion of the problem, it’s various facets, and how they effect possible solutions, one not only misses out on understanding the problem, but also in understanding the solution.

It really is a poor craftsman who blames his tools. The problem is being focused on solutions, and that doesn’t come from Design Patterns, it was there before hand (as demonstrated by The Plank).

In retrospect, I think the real mistake some pattern advocates may have made was in encouraging people who just didn’t get it, or didn’t want to get it, to use patterns anyway. To really mix up some metaphors: once you’ve brought the horse to the fountain of knowledge, if it doesn’t drink, just shoot it and put it out of its misery. If you force it, it’s just going to pretend to drink while secretly gargling, and you’re going to find yourself stuck in the middle of the desert with a dehydrated horse. ;-)

"Leading the Horse to the Fountain of Knowledge" by Christer Ericson

Sun, 04 May 2008 23:20:37 -0700

Bingo, Chris. My issue isn’t with design patterns per se, but the large number of people who wield them as hammers. (That said, as long as such people exist, I’ll be against design patterns in the same way I’m against guns.) A rant just isn’t as good if you simply spell it out, so I didn’t. Spoilsport!

Xblog: Leading the Horse to the Fountain of Knowledge

Leading the Horse to the Fountain of Knowledge

"Leading the Horse to the Fountain of Knowledge" by Christer Ericson