The Common Misunderstanding of Design Patterns

A little while ago, I responded to Andrae talking about how patterns were just language defects. As I pointed out, "Design patterns are not reliant on OO, Java, C++ or any particular language or programming paradigm." and as an example the singleton pattern disappears when you use Spring et al.

Similarly, a much more popular blogging group are talking about the same thing with "Ralph Johnson on design patterns" and one of the author's of "Design Patterns" response, "Design patterns and language design".

Mark Dominus writes,

"If you're a language designer, and a "pattern" comes to your attention, then you have a great opportunity. The programmers using your language have a recurring problem. They have to implement the same solution to it, over and over. Clearly, this is a good place to try to expend some design effort; perhaps you can trade off a little simplicity for some functionality and fix the language so that the problem is a problem no longer.

Getting rid of one recurring design problem might create new ones. But if the new problems are operating at a higher level of abstraction, you may have a win. Getting rid of the need for "subroutine call" pattern in assembly language opened up all sorts of new problems: when and how do I do recursion? When and how do I do coroutines?"

And Ralph Johnson,

"No matter how complicated your language will be, there will always be things that are not in the language. These things will have to be patterns. So, we can eliminate one set of patterns by moving them into the language, but then we'll just have to focus on other patterns. We don't know what patterns will be important 50 years from now, but it is a safe bet that programmers will still be using patterns of some sort."

So this goes to the heart of what good design is. Putting in double dispatch or multiple inheritance is not necessarily an overall win in language design whereas something like closures may be. But like most things, especially related to design, proficient users are usually too close to the problem to make the right call.