13

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 ?

Eduard Florinescu
  • 973
  • 2
  • 12
  • 32
  • 16
    It would be a mistake to accept anything that Paul Graham says on the subject of programming languages as "objective and factual." – Mason Wheeler Sep 20 '12 at 20:13
  • 5
    I don't tend to disagree with Paul Graham, but @MasonWheeler is right, evangelists are great for many reasons, but not for their objectivity. – Jimmy Hoffa Sep 20 '12 at 20:39
  • @JimmyHoffa At least did he had intuition, are there confirmation or invalidation of his claims? I think and saw that some of the businesses have this knowledge of what works and not and where and with what people at least in there area, but they tend to keep this very useful information for themselves. – Eduard Florinescu Sep 20 '12 at 20:44
  • 3
    @JimmyHoffa: It's not "evangelists" in general. I take issue with Graham's long history of posting ridiculous material that frequently contradicts himself or his sources and trying to twist the whole thing into appearing consistent. No matter what it is you're advocating for, that's a horrible way to go about it, and it's a bit appalling to me that people actually listen to him. – Mason Wheeler Sep 20 '12 at 21:52
  • 5
    Would be nice to see some studies, but if you ever used modern functional languages - you already know how obsolete GOF design patterns are, and there is no need for number to prove it _more_. (Though, they were important in 1990, no doubt). – c69 Sep 21 '12 at 01:06
  • 2
    Design patterns are not related to the languages and their deficiencies. They're more about the ugliness of the OO approach in general. Patterns usually appear when a not quite suitable model is used to describe entities that should be better described some other way. – SK-logic Sep 21 '12 at 12:29
  • @SK-logic - I think that's what I'm saying in my answer, just in a slightly more positive light. In your opinion, is there a better, non domain-specific paradigm, in general? Specifically, with the language being a suitable model for "everything". – Daniel B Sep 21 '12 at 12:34
  • 3
    @DanielB, every specific paradigm will fail, because the reality is much more complex than any paradigm could ever be. Therefore, each and every problem deserves its own, domain specific model and paradigm. – SK-logic Sep 21 '12 at 13:01
  • 1
    @SK-logic thanks, and I agree. Unfortunately I'm stuck in OO-land most of the time (we don't always get to decide the technologies applied), and have to coerce the language to fit the problem. I find it to be OK, as long as you do it cleverly. – Daniel B Sep 21 '12 at 13:38
  • @DanielB, of course you can use an OO language for building non-OO models. OOD is a problem, not a lower level OOP. You can build domain-specific models and then encode them in an OO way, it's not a big deal. And this way you won't see that much of the "design patterns". – SK-logic Sep 21 '12 at 14:48

1 Answers1

11

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.

Daniel B
  • 6,184
  • 1
  • 22
  • 30
  • (+1) and accept because you narrowed my search on DSL and application patterns. Very thoughtful, and can you please expand or link for the reader maybe in parenthesis at least one of the DSL acronyms I suppose it means Domain-Specific Language. – Eduard Florinescu Sep 21 '12 at 11:50
  • @EduardFlorinescu thanks, I've updated with links for DSL. – Daniel B Sep 21 '12 at 12:22
  • I also found this article confirming part of your answer in this case with Groovy http://www.ibm.com/developerworks/java/library/j-eaed7/index.html – Eduard Florinescu Sep 24 '12 at 11:54
  • 1
    @EduardFlorinescu that's very interesting, although I wasn't just referring to the interpreter pattern specifically; rather, I meant that many patterns can be quite domain-specific, and become almost idiomatic for developers in that domain. In that sense, they become a kind of DSL, and don't take up much effort to understand and use. E.g. when I read through a command pattern (a non-domain specific example), I know which boilerplate code I can safely ignore, and it doesn't take much effort. But thanks for the interesting link, nonetheless. – Daniel B Sep 24 '12 at 13:31