#### Archived

This topic is now archived and is closed to further replies.

# Are design patterns language neutral?

This topic is 5505 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

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? My view-point is the later, that the GoF patterns are abstract enough to apply to any object-oriented design in any environment. A decent example is the creational design pattern the ''factory method''; it''s use is demonstrated by the following code:
msg = deserialize(data);

msg is assigned to some object that deserialize determines using a moniker-to-class mapping. The moniker is contained inside of ''data'', and deserialize creates a known class from this information (else it generates an error). Possible implementations are to sub-class and provide a method to return a class object and then create an instance of it (SmallTalk), sub-class to build an explicit mapping and create a default instance (C++), or use parametric polymorphism and call a pre-determined method given a set of classes (Python).

##### Share on other sites
I''ve read some books on the subject that does not have even a single line of pseudo-code. I think that design patterns are a guide for good designs and its up to you to adapt the design to the language you are going to use, if it''s possible.

##### Share on other sites
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.

##### Share on other sites
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.

##### Share on other sites
quote:
Original post by SabreMan
Disclaimer: I don''t have the book in front of me to confirm the exact wording, but that should be a sufficient paraphrasing.

"The choice of programming language is important because it influences one''s point of view. Our patterns assume Smalltalk/C++-level language features, and that choice determines what can and cannot be implemented easily. If we assumed procedural languages, we might have included design patterns called "Inheritance", "Encapsulation" and "Polymorphism". Similarly, some of our patterns are supported directly by the less common object-oriented languages. CLOS has multi-methods, for example, which lessen the need for a pattern such as Visitor. In fact, there are enough differences between Smalltalk and C++ to mean that some patterns can be expressed more easily in one language than the other."

##### Share on other sites
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.

##### Share on other sites
quote:
"The choice of programming language is important [...]

Thanks. Fairly conclusive wrt the original question.

##### Share on other sites
Could one say that the GoF "patterns" are in fact establishing a sort of basic vocabulary of software engineering - a set of language concepts that are useful, probably necessary, but not always available directly through the language?

It could explain why the book is so popular among C++ programmers, because it completes their vocabulary, making them more versatile programmers.

##### Share on other sites
I''d like to see someone implement a factory in LISP, I could probably do it in BASIC but not in FORTRAN.

So my answer is no. The GoF patterns are not language agnostic (nor are they thread safe).

But then again define a computer language. Some languages are marely subsets and used for educational purposes only (well they did when I was in school), and others have specific uses (ADA). So really we need to define what are qualifying langauges, after all the Ti rang of calculators have a language as well.

##### Share on other sites
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"

• 10
• 18
• 14
• 18
• 15