A fresh look at patterns (revisited)

Mark-Jason Dominus responded (via email) to the commentary in my previous post. Now I know that I was wrong in thinking he’d misunderstood patterns. His stance is that several patterns are made obsolete by the advance in programming languages (he mentions Haskell, Perl and Common Lisp) and that the pattern authors perhaps more clearly should state which patterns are motivated by (lack of) language features.

He gave a brilliant example of how in C there was what might be called the “object-oriented class pattern” (although patterns hadn’t been introduced into software engineering at the time), which in C++ was “folded back into the language”. One might say that the Iterator pattern was “adopted” by Java, in the form of Enumeration (and later as Iterator).

His email made me think that design patterns “take over” where the programming language isn’t sufficient to deal with the ideas of the programmer. Before C++, there “was” a pattern for representing objects in C programs. Now, we have patterns for concepts for which the programming language doesn’t have direct support, and that might be obsoleted by future languages. I also came to think that language developers might capture in patterns what should be supported by new languages.

Then there are the more abstract patterns that aren’t replacable by language constructs, such as Facade and Factory. The motivation for such design patterns are to assign responsibilities cohesively and to keep coupling low (as expressed by the patterns High Cohesion and Low Coupling, which are more like “meta-patterns” in this case). Patterns such as these are more generic and will therefore live longer.