quote:Original post by Magmai Kai Holmlor
Are design patterns language specific idioms, or do they transcend programming languages, and apply equally to C++, Java, SmallTalk, Python, etc.. & even to the CLOS?

There are two ways of looking at it. Many of the GoF patterns are very language-specific. For example, they even point out in the book that CLOS doesn''t need Visitor, and they explain (I think) in the introduction that if they were writing the book with C, then single despatch would be a pattern. So, even GoF admit this. Disclaimer: I don''t have the book in front of me to confirm the exact wording, but that should be a sufficient paraphrasing.

The second way of looking at this is to consider that, just because we cannot find a language that doesn''t require a particular pattern doesn''t mean that the pattern transcends languages. It might mean simply that we don''t know of a "better way". It''s important to recognise the underlying purpose of Design Patterns, which has been discussed in NotAnAnonymousPoster''s recent thread. It''s fairly apparent to me (and not just me) that GoF''s patterns are not what Alexandrian patterns are about. It is better to call them idioms, even if we consider that some of them are language agnostic idioms (which is quite a hard claim to support). What''s in GoF is at no different a level to what''s in Coplien''s Advanced C++, the O''Reilly cookbooks or even something like the "Effective" books. Patterns are supposed to be different to that.

I think design patterns fall into two parameterized categories: language -non-trivial and language -trivial. Let''s take my favorite design pattern: "addition of integral numbers". Probably your language of choice makes using the "addition of integral numbers" pattern pretty trivial. But if you program on a Turing machine, or in a pure lambda calculus, or even Brainf*ck, then the "addition of integral numbers" pattern becomes non-trivial.

Consider single dispatch. In C you need to set up your function pointer tables and copy the pointers to the tables manually. In C++, you just add the virtual keyword in a few places and you''re done. Single dispatch might be considered C-non-trivial and C++-trivial.

Consider the factory method of serialization/deserialization. In C++ you need to set up a system of type id''s, generate a mapping somehow, make sure the right functions get called, etc. In C#, you slap the [Serializable()] attribute on a class, and you''re done. So the factory method might be considered C++-non-trivial and C#-trivial.

The fact that a given language makes fill-in-the-blank easy, doesn''t make fill-in-the-blank less of a pattern. If anything, it validates its existence as a pattern. After all, if it''s not worth doing, why make doing it easier? And if it''s a really great pattern, we might start hardware accelerating it. E.g. math co-processors for the "floating point addition" pattern, or 3d acceleration for the "draw a triangle" pattern.

Oh, and I was kidding. "Addition of integral numbers" isn''t my favorite pattern; "halting program execution" is my favorite pattern.

quote:Original post by SiCrane
Let''s take my favorite design pattern: "addition of integral numbers".

Let''s not. It''s not a design pattern, which is the point I''m trying to make. There''s two issues. I think Magmai is asking "are GoF patterns/idioms/whatever language agnostic?" rather than "are patterns language agnostic?". I''m pointing out that GoF "patterns" are neither language agnostic nor even patterns. Once we stop considering GoF patterns to be correct patterns, we can stop being surprised when we find things out about them such as "CLOS doesn''t need Visitor", and we can get on and assess them in a more rational manner. As long as we insist they are something more than language-specific idioms, we continually run the risk of abusing languages and idioms. This is the reason some people consider GoF, or rather the aura surrounding GoF, to be harmful.

quote:Original post by MadKeithV
"The choice of programming language is important [...]

Thanks. Fairly conclusive wrt the original question.

quote:Original post by SabreMan
Let''s not. It''s not a design pattern, which is the point I''m trying to make.

Ok, I''ve yet to see you post this, but what exactly is your definition of a design pattern, and why wouldn''t this be a pattern? Or, if your definition is an entire book taking 500 pages because you want it that precise, what clauses of your definition is it violating?

quote:
There''s two issues. I think Magmai is asking "are GoF patterns/idioms/whatever language agnostic?" rather than "are patterns language agnostic?". I''m pointing out that GoF "patterns" are neither language agnostic nor even patterns.

Even Richard Gabriel has been known to refer to the GoF "patterns" as patterns. (Maybe it was a moment of weakness, who knows?) However, for better or for worse, many people, including Doug Lea, classify language-specific idioms as patterns. Albeit, patterns that have context clauses like: "AND you''re using a brain dead language".

quote:
Once we stop considering GoF patterns to be correct patterns, we can stop being surprised when we find things out about them such as "CLOS doesn''t need Visitor", and we can get on and assess them in a more rational manner. As long as we insist they are something more than language-specific idioms, we continually run the risk of abusing languages and idioms. This is the reason some people consider GoF, or rather the aura surrounding GoF, to be harmful.

I agree that the GoF book is an imperfect example of design patterns. However, I do so, not because I consider the patterns not to be patterns, but because the patterns possess implicit restrictions not specified in the context/motivation portions of the pattern descriptions. Moreover, the alternatives to when those implicit restrictions are gone are not presented (or at least not adequately presented).

And I think that far fewer people would be confused about the visitor pattern, had they named it after the problem it was meant to solve instead of a clever metaphor for how the solution is implemented.

Here''s a question for you: do you consider any of the GoF patterns to be "real" design patterns? Or does the whole thing go in the rubbish bin of idiom?

It could just be that we need to agree that we disagree on what "design pattern" means. In my definition, you have the umbrella set "Patterns". "Patterns" then has the subsets "Software Patterns" and then "Architecture Patterns", "Stuffed-animal Patterns" etc. In "Software Patterns" you have the subsets "Design Patterns", "Analysis Patterns", "Development Patterns", etc. In "Design Patterns" you have "Programming Idioms", "Algorithms", "Data Structures", "Protocols", etc. Of course these aren''t necessarily disjoint subsets. "Algorithms" has a non-empty intersection with "Data Structures"