Patterns Show Weaknesses

Some patterns show weaknesses in the languages that require them. These are some examples I thought of. Feel free to add/remove/modify/comment them. -- AurelianoCalvo

StatePattern: Inability to change the object class (and underlying behaviour).
ResourceAllocationIsInitialization: Inability to pass code to a method (see how files are handled in RubyLanguage and LispLanguage).
- Hmm. RAII is mainly (only?) seen in CeePlusPlus, where the ruby/lisp method of using a HigherOrderFunction is also possible. So is this really weaker or just different?
- In fact isn't it obvious that if your RAII object is also a functor, that accepts another functor as an argument, these are exactly the same idioms?
SingletonPattern: Can't set behaviour for a single object.
DecoratorPattern: Inability to add behaviour to an object (the decorator and the decoratee represent the same underlying object).
PimplIdiom: Can't separate interface and implementation cleanly. Well, CeePlusPlus is so #$^%#$#&@ that it has its own exclusive patterns.

I don't understand the weakness for DecoratorPattern. Would someone give an example? -- JasonFelice

If you can dynamically add behavior to an object, you don't have to use a decorator class. -- EricHodges

Not true! You have a FileParser which delegates to a FileReader. You make a GzipReader decorator for the FileReader so you can read compressed files.

(And, I might mention, I spend a lot of time with RubyLanguage and poke and override methods on classes which are not mine all the time. It's just that in this case, it would make FileReader heavy. You'd be introducing a StrategyPattern anyway if you made the one class handle both cases; DecoratorPattern seems simpler.) -- JasonFelice

Well, forget classes for a moment. If you were able to replace the "read" method with a new one in the object that is required to uncompress the gzipped file, you wouldn't need to use the decorator. The advantage of this posibility is that it's not possible to call the decoratee (why would the programmer want to read without uncompress). But the real reason is that both decoratee and decorator refer to the same conceptual object.

You are talking about extending an instance then. OK, but you need to change "read", "write", and "seek" messages, which are defined in terms of the underlying primitives in this case. You could poke a method onto the class "make_compressed" which would redefine those three methods, but what advantage is this, compared to DecoratorPattern? Hmm. What language are you thinking in?

Object means instance, btw, when you can add/change/remove behavior from an object, you don't need decorators, JavaScript and SelfLanguage, PrototypeBasedLanguages, are examples of this idiom. (So is RubyLanguage.)

OK, I'll agree that a language's requiring the use of DecoratorPattern shows inability to add behavior to an object. The page title originally suggested to me that use of these patterns shows the language weaknesses. -- JasonFelice

Doesn't AreDesignPatternsMissingLanguageFeatures already cover this?

Well, yes, but ResourceAllocationIsInitialization and the PimplIdiom are not canonical "DesignPatterns".

Perhaps they should be on IdiomsShowWeaknesses? then? It might be interesting to consider natural languages too?

Well, yes, but ResourceAllocationIsInitialization and the PimplIdiom are not canonical "DesignPatterns".

There's a canon for design patterns now? Did I miss the Pattern Pope's council?

No, you've just forgotten the magical transformation that happens to information when impressed upon trees - especially when encased on three sides with stiff pieces of heavily compressed tree-pulp with ribbon appendages. Once corporealized upon pressed-tree-pulp, it can be put to the useful end of meeting social recognition needs if properly displayed.

It seems to me that RAII and pimpl are not "Design Patterns" in the sense of being patterns for the abstract design of software, so much as they are techniques for getting around some of the perceived shortcomings of CeePlusPlus.

PatternBacklash

JulyZeroSix (but barely so)

CategoryPattern