“Design Patterns” Aren't (2002)

I remember reading this when it was new. foreach only works on a list. I can bless a list of lists into a rose tree, but i can't traverse that in a uniform way. There's just no hook to say, when the thing isn't a list, get the next element like this. Now days i'd point at haskell's traversable as the gold standard. On large java projects it seems like composite/facade for days. Those splits seemed to let teams work…

The best explanation I heard of design patterns is, that they are not a template to slavishly follow when producing code, but a common language to talk about code. So you should be able to go and identify, look, this is an iterator, this is a command pattern, this is a monad, and you have a clear and concise way to reason about your code and talk to other people. The second best explanation is that patterns are often a…

In his postscript the author explains that he wasn't trying to criticize design patterns, but was rather trying to promote this other concept; which, supposedly, is little known in CS circles because of the similar names... His summary: "We need to take a fresh look at Christopher Alexander." That's all well and good, and as far as I know the concept of pattern languages could be very useful; I wouldn't know, I've never heard of it till today, and in…

I sympathize with the critique of GoF design patterns, but the author is seriously distorting Alexander in his eagerness to dissociate him from them. "How can you distribute responsibility for design through all levels of a large hierarchy" is not the theme of A Pattern Language, which is easy to see when you consider that the book is largely about dwellings (which don't involve any large hierarchies). I agree, though, that the most interesting aspects of Alexander never made it…