The “Design Patterns” book is one of the worst programming books ever. Yes, really. I’m 100% dead serious when I say that I think it has set (and will continue to set) the progress of software development back by decades. Why?! Let me offer up a parable; I will call it “The Plank.”
Back when I took computer science, as part of the curriculum was a compulsory class in statistics. Two of my closest friends (Olle and Martin) and I scoffed at this statistics class — we were computer scientists for chrissake, we don’t care about statistics! — and kept postponing the class year after year, until we basically had to take it in order to graduate. Still, we resisted up to the very last minute. Sure, we went to a few lectures, but didn’t pay attention, didn’t do any exercises, or anything. We sort of were planning to postpone it another year, because… duh… statistics! Except, the Friday before the Monday of the exam, Olle (I think) really insisted we should take the exam and get rid of this horrible thing once and for all. His brilliant idea: just cram all weekend and do the exam on Monday! Reluctantly we all agreed the time had come and it was the right thing to do.
The plan of attack that we devised was to go through the exams of the last several years, look at every question that was asked and see if we could identify questions or question categories that recurred, and learn enough categories that we’d get a passing grade on the course. I don’t recall the details, but let’s say that the typical exam had 10 questions, worth 5 points each, and you needed 25 points for a passing grade (50%) and 38 points for passing with honors (75%). Thus, we needed to learn 5 categories and ace the questions to pass. To err on the side of caution, I think we identified 8 question categories from combing through the old exams (which you generally do get access to in Sweden) for several hours. We then sat down, split the question categories amongst us, and each studied only the text book chapters relevant to our own categories. After cramming the chapters enough that we could solve questions from that category, we taught each other what we had learned, and the steps to solving these questions.
One trick we devised was to create our own stereotypical problem for each problem category, and we pretty much memorized its solution as a means to remember how to solve problems in that category. I only vaguely recall one particular stereotypical problem that we had named “The Plank” because it involved sawing a wooden plank in two and somehow looking at the distribution of the lengths of the two resulting pieces.
We spent Friday evening and all of Saturday and Sunday doing this. Sunday, Olle brought along caffeine pills as an extra study aid. Everything to give us the edge in defeating the statistics beast!
Monday morning as we gathered outside the exam room, Olle looked like a man possessed. He had stayed up all night, popping caffeine pills like they were peanuts. “I feel good about this,” he said as we entered the room. Finally, sitting down with the dreaded statistics exam in front of me, I dove right in quickly trying to solve as many problems as possible with the limited statistics knowledge I had crammed into my head before it evaporated! To this day I vividly recall looking at one of the questions of the exam, thinking “Yes! Score! It’s The Plank!” and furiously scribbled down the solution I had memorized, but applied to this incarnation of the problem. Six long hours later the exam was over and the three of us met outside. “I think I aced it,” Olle exclaimed. Martin and I weren’t quite as confident.
Two weeks or so later, we finally got the results. Olle didn’t quite ace it, but he did get over 75%, passing with honors. So did Martin. I was 3 or 4 points shy of the 75% limit, only getting a passable grade. Looking over my answers I soon found out why. I had a zero on The Plank question! Reading the question again, suddenly it was clear to me: it wasn’t The Plank, it just superficially looked like The Plank! It was also painfully clear to me that had I paused and thought about the problem for a while, I would not only have realized this, but I would also have nailed the question, because I knew how to solve it!
If you didn’t guess it already, The Plank is a design pattern. In this case, I had focused so heavily on the design patterns we had identified that I was seeing solutions before I was seeing the problem! I would have done much better not learning any of the patterns in the first place, just relying on the skills I had obtained through study, which got me through all the other questions.
Stay away from the box, or I’ll smack your head with the plank
How does that story relate, you ask? I’ll tell you. 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. Such thinking, whether intended or not is, of course, utter nonsense. Worse, it’s pure poison to the malleable brain of a young programmer! 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…
As if spreading poisonous mind rot wasn’t enough, the other outrageous thing about the Book From Hell is that it took stuff that had been known forever in computer science circles and renamed things we already knew by some other name (or indeed no name at all, because it’s blatantly obvious). 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.
Peter Norvig has a more reasoned presentation on why design patterns are completely not needed if you use a reasonably modern programming language (instead of tripe like C++ and Java).
Design patterns? Just say no!