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 book from The Gang of Four is “one of the worst programming books ever”. It wouldn’t make my list (Beyond Java was pretty bad), 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 (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!
SomeGuy | 01-Aug-08 at 1:20 am | Permalink
Kids today and their fancy language …
I think you have hit on the single biggest problem with design patterns: people act as if it was something brand new that was introduced into the programming world and that it revolutionized it. In reality they just gave a name to something that had existed before.
They have revolutionized communication though. Having a conversation with someone and saying “apply the visitor pattern” instead of “traverse through the nodes of a tree and ” etc. etc. does have some merit.
Tim McClarren | 01-Aug-08 at 2:09 am | Permalink
Thanks for this… it summarizes well what I’ve felt about programming for nearly 15 years now. I’ve left Java-land for the pure and clean land of C (alright, C++, but that’s not pure or clean) again a few years back. I had even worked on a Java IDE. I had also been interviewed by Ralph Johnson, albeit very briefly, back in 1990 before the Gang of Four book went into print (I was very young at the time, and a colleague said that after Dr. Johnson left, I said it was like “two ships passing in the night”… I had no understanding of his theoretical framework, and in fact, I don’t even recall whether he tried to help me understand it… he purported to just be asking software professionals about their experience in the field, and at the time I was a fairly prolific USENET poster on the Objective-C newgroups, and I’m guessing that’s where he found me). I think there is some value for a taxonomy of software design, but, frankly, way too much is made of design patterns. Good programmers understand those idioms in several languages, taxonomy or not.
Sadly, I think that Java programmers (I mean programmers who exclusively program in Java) pay far more attention to this stuff than do other programmers. I’m not knocking Java, it’s fine. The problem is that it’s used exclusively in some places, and it doesn’t allow for people to understand how other paradigms, other languages, and the hardware itself actually function (and no, understanding the VM and understanding how the VM interacts with the CPU pipeline, the branch predictor, the instruction and data cache, etc., is entirely different… ).
troelskn | 01-Aug-08 at 4:02 am | Permalink
In a way you did in fact miss the boat. Patterns have two qualities. The immediate is as a blue-print for solving a specific class of problems. This is the aspect that most people (Especially programmers with lesser experience) focus on, because it makes the pattern a tool that they can use in their work. Used this way, the theory is, you may have a problem and you can then find a pattern that is designed to solve this problem and if you apply it, you have done good. This kind of thinking isn’t overly relevant for someone with much experience as a programmer; Indeed it may become more of a hindrance than a help.
The other quality of patterns is to form a common language to describe certain things that we, as programmers, do. I say “I’m using an abstract factory to decouple these two classes”, and you know what I mean. Such words make it easier for us to communicate with each other, so that we can discuss the really interesting stuff (Which is not the details of the “abstract factory” pattern).
Of course I can’t know the details of the situation you described above, but if you had known the concept of fly-weight pattern, you could have easier communicated your intend to him, instead of having to explain in detail how you program worked.
Paul Keeble | 01-Aug-08 at 5:14 am | Permalink
In functional languages patterns are less necessary (if at all) because they aren’t limited in the way that C/Java like languages are. It is that limitation of aspect like programming and the importance placed on the objects and their structure which makes “normal” programming languages structure.
There are however still patterns of behaviour in functional programming, just no one has written enough about them yet to recognise the patterns. Todays patterns are tomorrows programming features and I think the reason Java’s patterns are so obvious is because of the more advanced languages like LISP.
Fadzlan | 01-Aug-08 at 6:23 am | Permalink
I agree with you that these things come up at awkward places, but you got to give it credits.
If there are other things twice as useful, you’d probably hear them in awkward places too. People just like to look as if they know something, which is even easier if there are names attached to it.
Matt | 01-Aug-08 at 6:49 am | Permalink
Apologies in advance if this comes across as rude, but I felt I needed to give you some heat for this: a new hire asked you to buy a $50 tech book for him so he could improve his skills and you said “no”?! Ouch. If that’s typical of your work culture, it must suck to be a motivated self-improver in your company.
Tom Ritchford | 01-Aug-08 at 6:57 am | Permalink
“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[...]”
Wait, you turned down someone’s request to buy a technical book?? And I’m supposed to take the rest of this article seriously? Not that I love the book but it seems very much penny wise, pound foolish to refuse book requests…
Leo | 02-Aug-08 at 5:05 am | Permalink
“In my experience, you never see Lisp programmers hanging around talking about design patterns – they’re usually talking about something much more interesting.”
And most of us never see Lisp programmers hanging around. There [1] is a nice response to this post. And I totally agree with that.
[1] http://kawagner.blogspot.com/