views:

111

answers:

9

Question over here is are design patterns specific to a programming language or technology,

Like you can do composite pattern only in C#,Java but not in VB6.0.Is that true, If yes that what are pattern that can't be implemented with out object oriented programming languages.

+1  A: 

I think that it depends more on what language features are available to you, but no, I wouldn't say that design patterns are constrained to particular languages.

Matt H
A: 

no,they are not.

MindFold
+2  A: 

Patterns depend on programming languages, although not so strongly as your question suggests. For example, Iterator is a design pattern, however in many languages (C++, Java, C#) it is part of the language (OK, the class library).

There are several patterns which can be called Object Oriented, i.e. it is difficult to implement them without proper classes, inheritance and polymorphism. Examples: Abstract Factory, Strategy, Template Method. However, even these could be done in e.g. C, if someone really wanted. This is possible because C has function pointers. I would be very hard pressed though to imagine an implementation of the above patterns in a non OO language without pointer (or equivalent) support. Then again, I guess these patterns wouldn't really make sense in such a language anyway...

Péter Török
I know someone who really wanted to, I am maintaing there code as we speak......
hhafez
As a corollary, most design patterns are effectively replacements for features absent from the language. Strategy and command, for example are workarounds for a lack of first-class functions. Wikipedia's Ruby strategy example with blocks illustrates this point perfectly (keeping in mind that blocks are just a special syntax for anonymous functions). Composite is a workaround for a lack of generic functions, as illustrated by Wikipedia's example in Common Lisp. I suspect one could match most design patterns to a language feature in this way.
Zak
a disruptive article by Mark Dominus illustrating @Zak's point - http://blog.plover.com/prog/design-patterns.html
Anurag
A: 

Most of the patterns are language independent. For some patterns and languages major hackery is needed. For example windows COM is a bizarre implementation of composite pattern in C (not C++) language.

Some languages like VB 6.0 put up major hurdles that need to be jumped over to implement some patterns, thus making it not worth the effort.

Vlad
A: 

Yes and no. Certain design patterns are not specific to particular languages, but there may be design patterns specific to classes of languages.

For example, there may be functional design patterns that are specific to functional languages or object oriented design patterns specific to object oriented languages. Some overlap may exist, but it is not 100%.

mcliedtk
+1  A: 

Design patterns are not language specific per se, however some patterns can be paradigm specific, for example implementing a singleton pattern in C makes no sense as you might as well just write a plain old module.

However design patterns are not language specific but can be more useful or make more sense in different paradigms (OO vs structured vs functional)

hhafez
A: 

This is to give a straightforward answer.

On one side some patterns are language dependent, patterns like Factory, Strategy and Template rely on language mechanisms like polymorphism and inheritance.

On the other hand some patterns exist because language we use doesn't have the right functionality (example: Visitor pattern is used to make up for the lack of double dispatch in languages like Java and C++).

Daniel Fath
+2  A: 

Among the classic 'Gang of Four' patterns, quite a few are language-specific. Others, like Visitor, are really useful only in an object-oriented setting. Functional language have fold (catamorphisms) instead of Visitor, and anybody trying to use Visitor in a functional language would be viewed as a dangerous lunatic. Finally, there are patterns that could be applied in any language, like Factory.

One of the reasons I'm not a big fan of the patterns movement as practiced by Gamma et al is that the view of pattern lacks intellectual coherence. "Anything useful" is a nice claim, but doesn't, as you observe, give much guidance as to which patterns might still be useful when language or paradigm changes.

For a illustration of the risks inherent in classifying patterns, check out one of my favorite collections: Kent Beck's Smalltalk Best Practice Patterns. Despite the work "Smalltalk" in the title, many programmers have found these patterns applicable to languages like Java and Python as well.

Norman Ramsey
A: 

Design patterns are not inherently language specific, although some patterns are more useful in some languages than others.

Doug