Design patterns (by alaric)
I'd thought I'd had this little rant before, but as I went to find the post I'd had it in to link to it from a big ranty post I'm working on, I couldn't find it.
So here it is.
My opinion of design patterns.
Design patterns are common structures that appear in computer programs, but that can't themselves be abstracted into a reusable component.
That's fair enough. I have the "gang of four" book of design patterns, that started the craze, and I think they're all good design patterns in mainstream OO languages; things that can't be actually encapsulated as a class or whatever, but that keep cropping up.
However, the problem is that the patterns community has somehow ended up with some dogmatic folks in it. Who take phrases such as "Design patterns are common structures that appear in computer programs, but that can't themselves be abstracted into a reusable component" - and then attack anybody who claims to have encapsulated a design pattern into a reusable component.
Because design patterns are really only valid in relation to a set of languages. For example, in assembly language (or even traditional BASIC with GOSUB), procedure calls are a design pattern. There is no language construct for a procedure; instead, you have a GOSUB or CALL to a given address, that explicitly saves the calling location somewhere and then jumps, and a RETURN to go back to that saved location. The GOSUB...RETURN pairing is put in there by the programmer; it's a design pattern.
But then higher-level languages have explicit procedure abstractions, and all the fun they entail.
Even object orientation is a design pattern in languages like C. "Put function pointers in a struct, and call them with the struct pointer passed as the first argument". Or including a pointer to a struct of function pointers in every data struct (and call it a virtual method table). But go to Java and that's an explicit language abstraction facility.
The gang-of-four book is taken as the authoritative book of common design patterns (although it is, in my opinion, a book of design patterns for mainstream OO languages). And design patterns are things that cannot be expressed as native abstractions in code. THEREFORE, fools think, it's impossible to write a design pattern in code. And anybody who claims to have done so needs shouting at.
Sadly, as demonstrated in Peter Norvig's presentation on design patterns in dynamic languages, more advanced languages can express abstractions that others can't, and there are plenty of more advanced languages than C++ and Java.
In fact, I think that the appearance of design patterns in a language is probably a hint that the language needs to be more powerful - and suggests how to make it so. What sort of abstraction would make it possible to encode your design patterns?
And so, as I read "Modern C++ Design" by Andrei Alexandrescu (a book on doing good things with C++ templates), I come across the following phrase:
Eventually, Andrei turned his attention to the development of template-based implementations of popular language idioms and design patterns, especially the GoF [gang of four] patterns. This led to a brief skirmish within the Patterns community, because one of their fundamental tenets is that patterns cannot be represented in code. Once it became clear that Andrei was automating the generation of pattern implementations rather than trying to encode patterns themselves, the objection was removed...
Bleargh. It sucks when people get all religious about the interpretation of a given piece of "scripture". Even when people manage to work around it by using illogical arguments ("No, no, it's not a representation of the pattern in code, it's a bit of code that automates the creation of implementations of the pattern..."). Sadly, in other realms, this kind of thing can lead to people being burnt at the stake.
Mon 29th Dec 2008 10:02 pm 
Subscribe
By Dale, Fri 28th Aug 2009 @ 8:43 pm
Couldn't agree more, but, unfortunately I think you find this kind of rabid devotion common in many aspects of the developer communities. I've always thought of patterns as plastic, that they can change and bend, and even be discarded as the languages/environment/needs change - but try telling that to some people. You make a great point about more complex languages abstracting patterns themselves, but I think you could go further and look at frameworks like Rails and Cake. Although the languages might not abstract the patterns, the frameworks do, and in many cases to an extent that the developer need not even see the pattern in order to effectively use it - just like your great example about procedure calls in assembly. Great article.
By clord, Fri 28th Aug 2009 @ 8:52 pm
"automating the generation of pattern implementations rather than trying to encode patterns themselves"
They said the same thing about virtual function tables way back when too. "That's just a table of pointers passed around implicitly, it's not ACTUAL virtual methods."
Of course, now days compilers can actually recognize the pattern and convert explicitly virtual objects back into static calls when possible and safe, whereas the old grey C programmers with their tables of function tables either have to break the design pattern and dogma to match that performance gain, or else suffer through a lot of kludge.
By clord, Fri 28th Aug 2009 @ 8:53 pm
(this said by someone who maintains 200+kloc of C, cry)
By Matt V, Fri 28th Aug 2009 @ 9:10 pm
I'm not religious about tech stuff at all, but it seems to me you are very confused about what a pattern is. Take a non-programming example - baking a cake. The pattern 'baking a cake' is not a cake, and it is not a recipe either. When I say "I am baking a cake", you know what I mean, even if you don't know what kind of cake I'm baking, or what recipe I'm using.
So using a 'strategy' pattern in a program doesn't imply any particular language or code implementation, it is just a more general 'way' of doing something.
By Seth Veale, Sat 29th Aug 2009 @ 11:46 pm
Well said. Obviously a bit old now though 🙂
As somebody relatively new to programming (8 years, incl uni), and having learnt with languages like Java and then (pro/re)gressed to C and Lisp-derivatives later on, patterns seem a lot less interesting. Every API I used when I was learning had patterns in it, and the patterns are more or less obvious because of that. Reading GoF was a bit of an anti-climax. PoEA was a bit more interesting.
I look at patterns as a perspective on a problem. It's like loops and recursion being different but roughly equivalent perspectives on repetition.
What I'd like is a language with a good way of communicating perspective, rather than a bunch of "sugar" features.
By Trey Jackson, Sat 12th Sep 2009 @ 6:07 pm
Amen! While I agree that some design patterns are like "baking a cake" (e.g. MVC), many are only useful to work around language problems (for c++: pimpl, chain of responsibility, visitor, etc.).