So I’m browsing back through Christer Ericson’s blog and see his article Design Patterns are from Hell, in which he states that the original/classic Design Patterns: Elements of Reusable Object-Oriented Software book from The Gang of Four is “one of the worst programming books ever”. It wouldn’t make my list (Beyond Java), but it’s nice to hear someone else say it’s not the greatest thing since sliced bread. I’ve complained about design patterns to a few (tolerantly-amused) coworkers, and touched on it in an old anti-Agile essay, but I didn’t want to digress into an unfocused grumpy old programmer mode.
I didn’t learn about design patterns until relatively late, near the end of the 90’s, but that’s probably because I started programming before 1990 and I started my career in Lisp. In my experience, you never see Lisp programmers hanging around talking about design patterns – they’re usually talking about something much more interesting. And, per Peter Norvig’s argument, design patterns don’t seem all that important when you’re programming in Lisp. If you need to apply a function through a list or tree, it’s a natural feature of the language – you don’t need to announce “I think I will apply a Visitor pattern”.
I first heard about design patterns when a new hire in my group asked me if he could expense the design patterns book, which had been taught in his college. Since I’d never heard about it, I said no, but when he purchased it on his own and I leafed through it, I regretted my rejection – the book didn’t bring any epiphanies, but it’s nice to recognize all these techniques you’ve been using with names attached. And it turned out, I had heard of design patterns before – while taking breaks in the library of the Space Telescope Science Institute, reading Richard Gabriel‘s columns in the Journal of Object Oriented Programming on applying pattern languages to software, inspired by architect Christopher Alexander‘s attempt to create pattern languages for urban planning. (next time you get an interview quiz on design patterns, ask your questioner about the relationship to Alexander’s work and to what extent Alexander’s design patterns are considered successful – so there!)
Design patterns started to seem important after I switched to Java – the libraries just ooze design patterns, and you’re going to learn them names whether you want to or not (Factory, anyone?) But at least the Java API’s are well designed (the greatest appeal of Java for me) Since then, design patterns have come up only in annoying situations, for example:
- A VP of Engineering vigorously trying to convince I should have used the Flyweight pattern in one of my programs. It turns out I was using the flyweight pattern – I just didn’t know it was now a pattern and had that name, and even though I explained how my program worked, since I didn’t say “flyweight” he felt I was missing the boat.
- A review of a coworker’s fix to my code – he delightedly said “Ah, that’s a singleton!”, and proceeded to apply the fix clearly without understanding the code (there were multiple instances of the same code that each needed the fix – ironically, he missed that “pattern”)
- A coworker who called everything he did twice a pattern, even when it was terrible. Especially when it was terrible. With some exaggeration, it would be as if I deliberately had divide-by-zeros everywhere and called it a pattern, thereby justifying it as worthy code.
The same goes for refactoring – heard about, eventually read the classic book by (Martin Fowler), seemed somewhat interesting, useful insofar as support by tools like Eclipse, but now after listening to people talk about how they’re going to refactor today, when it should be a natural, ongoing, and unannounced part of programming (how would it go over in a scrum meeting if I said, “I’m going to type, today, maybe spend one hour backspacing, two man hours recompiling…”) – enough already!