Totaliter aliter. The idea behind a design pattern is that it’s a language-independent solution to a problem. There’s also room for language tricks out there, but that’s different.
I don’t think so. A design pattern should be moveable from language to language, but in a “primitive” language it may be too cumbersome to bother with, and in an “advanced” language it may be built right in (and is just a ‘language feature’ not a ‘design pattern’) or even superceded by something else (and thus something not to do!). For example, dependency properties (ie, data in different objects that automagically stays in sync) is a built-in feature of WinFX/.NET 3.0, was a design pattern in .NET 1.0, and would be “an impressive thing to pull off” in C. A true design pattern sits at the right spot of complexity within a given language where it involves more than a couple keywords but can be re-implemented from scratch each time.
I’m not sure that I can agree with this in general. The Visitor pattern, for instance, is just a patch for languages that don’t support multimethods.
This isn’t just one nice effect, this is in fact the whole purpose of design patterns. People who treat design patterns as code templates (as well as those who deride them as ‘mere code templates’ are missing the entire point.
One useful pattern book I found was “Head First Design Patterns”. It has a little cartoon that sums it up very well. One developer is saying “And here, I’ve designed an object that maintains a certain state, and maintains references to other objects that are interested in the main objects state, and when the main object’s state changes it calls a state change method on all the objects in its reference list.” Then the other developers give him the WTF look and say “Why didn’t you just say you were using an observer pattern?” That’s the beauty of it right there. It simplifies design-related communications while preserving all the meaning.
Most likely, if you’re a good OO programmer, you’re already using some form of patterns (or antipatterns) even if you’re not referring to them as patterns. And if you’re not calling them patterns, that makes not one whit of difference as to the quality of your product. Using named patterns just makes it easier to communicate the nature and intent of your design, if everyone on your team uses the same vocabulary of patterns. It also tends to help you think in more object-oriented terms.
Where it all goes wrong is 2 places: First, as I mentioned before, where people treat them as abstract modules to be reproduced verbatim and used as much as possible. The second problem is the mentality that the canonical Gang of Four book is both correct and complete in terms of all the patterns in the coding universe.
On the contrary, I think they can have the opposite (bad) effect. Some mornings you’ll come to work and see a dozen new classes where some newb has thrown the entire GoF pattern catalog at a problem, thinking how great it is to have all these sophsticated design solutions at one’s fingertips.
I think this is certainly true. Sometimes when people start talking about “Strategy Pattern”, everyone else thinks “ooh, he knows his shit”, and sort of relaxes while Buzzword Guy designs a house of cards. But that tends not to happen if the whole group is aware of what patterns are. And that’s really how it’s supposed to work, they’re intended to help people communicate complex intentions, not to serve as fancy pre-fabricated modules ready for you to integrate.