So, "Are Design Patterns Missing Language Features"?

Question

I saw, here on Programmers, the answer to this question: How does thinking on design patterns and OOP practices change in dynamic and weakly-typed languages? There I found a link to an article with an outspoken title: Are Design Patterns Missing Language Features. But where I found snippets that to me seemed very catchy and that can be probably verified against experience given there is an incentive for that , like:

PaulGraham said "Peter Norvig found that 16 of the 23 patterns in Design Patterns were 'invisible or simpler' in Lisp."

or another sentence that confirms what I recently seen with people trying to simulate classes in JavaScript:

Of course, nobody ever speaks of the "function" pattern, or the "class" pattern, or numerous other things that we take for granted because most languages provide them as built-in features. OTOH, programmers in a purely PrototypeOrientedLanguage? might well find it convenient to simulate classes with prototypes...

I am also taking into consideration that design patterns are a communcation tool. Because even with my limited experience participating in building applications I can see as an anti-pattern(ineffective and/or counterproductive) for example, forcing a small PHP team to learn GoF patterns for small to medium intranet App. I am aware that scale, scope and purpose can determine what is effective and/or productive, but still I didn't managed to find an technical overview about that.

I saw small commercial applications that mixed functional with OOP and still be maintainable, and I don't know if many would need for example in python to write a singleton , but for me a simple module does the same thing.

So are there studies, exhaustive articles or other form of exposition that takes into consideration design patterns vs. workarounds vs. simpler ways to do it, or replacements by language features ?

Answer 1

I'm not aware of any in-depth discussion or study which takes into account all of those things.

That said, the whole argument of "design patterns are just patching missing features in OO languages" is a bit thin, in my opinion. Yes, some design patterns are exactly that, they fill some common gap doesn't even exist in some other language X. These are typically your low-level, simpler design patterns, like some / many of the original ones in the GoF book.

But design patterns go far beyond those simple ones, and calling them missing language features stretches the imagination. Glance over Fowler's catalogue of enterprise application patterns, and think about what it would be like if those were all part of the core definition of a language. I guess you'd end up with domain-specific language (DSL) for enterprise applications (and a very complex one, at that).

So this is the thing, really - design patterns are way to come up with reusable solutions for particular problems (which are often applied in a generic, all-purpose language). This is where communication also comes in. If you tell me "we use Active Records", I already know quite a lot about your application, without spending minutes discussing what the various approaches are. So yes, design patterns do patch holes in the language spec. Is that all that they do? No - not by a long shot.

Edit:

In a way, what I am saying is that patterns allow OO practitioners to think on a higher level, and almost construct a type of DSL for their environment, while staying within their language's syntax. And yes, I've seen what happens when you apply them everywhere (see: AbstractSingletonProxyFactoryBean, yes, it exists), or think they are some kind of silver bullet. The point is that while they take a long time to get truly comfortable with, they are supposed to actually lower complexity by making things predictable / understandable at a high level. This is very different to being a patch-kit for the failings of your language.

Edit 2 - added the AbstractSingletonProxyFactoryBean counter-example to poke some fun at patterns. To be completely fair, when viewed from an AOP light, even this counter-example is defensible.