If it is technology specific, is it still a design pattern?

Question

I went to a .NET user group meeting tonight, and part of it revolved around the model-view-view model pattern, and it got me wondering if this qualified as a pattern.
The issue I have is that M-V-VM is extremely technology specific. If you do not use WPF and its binding mechanism, I don't see how you could use that pattern.
By contrast, most "classic" patterns are largely technology agnostic. The biggest assumption they make is that the language used is object-oriented, and typically supports inheritance. Beyond that, classic patterns are mostly about stating a general design problem, and proposing an approach to resolving it - but multiple implementations or variations are possible.
My question is then where do you draw the line, between what is a design pattern and what is a recommendation on how to use a very specific framework? If you know how to implement it and what language and technology you need to use to do so, is it still a pattern?

Answer 1

Can the underlying concepts that are necessary for the "approach" to work be re-implemented on another platform without violating any patents, intellectual property, or obscene amounts of work? If so, I'd say we can definitely still call it a design pattern in the sense you're getting at - just a new one that isn't easy to do widely yet. (Though even platform-specific approaches can still be design patterns for the smaller community that can use them).

Do also keep in mind that MVVM is just a specific implementation of the Presentation Model Pattern presented by Martin Fowler, which is certainly "classic" as you say, and platform-agnostic.

"Nothing new under the sun" as they say, just different arrangements of the same ideas. Principles are refined all the time, rarely new ones invented.

Answer 2

Patterns are not an island in some sea of other things. Its not black and white that something is a pattern or not; all patterns can be layed out on a scale and be various shades of gray between generic and domain specific, between process and code and pretty much any two other goalposts you happen to pick.

If its a recipe that's worth sharing or reusing in even slightly different circumstances, its a pattern.

Answer 3

Yes, Design Patterns are often dependent on the programming language and technology in use: for example, DPs dealing with explicit resource ownership play badly with garbage-collected languages, one working around the limitations of compile-time typing play badly with dynamic languages, and so on -- that's normal, perfectly fine, essentially inevitable.

"A recommendation" differs from "a design pattern" not by technology context, but by breadth and especially depth: a proper DP identifies two or more independently developed uses of similar approaches, delves deeper to see what common "forces" they were dealing with, and harps on from there, in a beautiful but heavy-weight meta-format. By contrast, a recommdendation is much less formal, deep, and broad!

DPs are never invented, they are discovered by pondering over existing code (two or more independently developed occurrences) that deal with similar situations, identifying the commonalities as "forces" driving the solutions, etc, etc. "DP" is such a popular, catchy term that it's used FAR more widely than it should be -0- go back to the sources and read, or re-read, Alexander's Timeless Way of Building and his other works, if you've lost your way through the thicket of DP's buzzwordhood, they'll help you find the trail again!

Answer 4

If you do not use WPF and its binding mechanism, I don't see how you could use that pattern.

Silverlight and Moonlight also support MVVM.

Answer 5

"Languages are based off paradigms", each paradigm has different ways to solve a problem. Design patterns happen to be common solutions, doesn't matter if it's language specific or not.