这是一篇译文，你可以参看本文在TSS上的
英文原文，这是我的第一篇译文，有很多不当之处请见谅，若能指出则更好了。
在GoF的设计模式那本书中作者清楚的指出在使用设计模式的时候所使用的语言是非常重要的：
| The choice of programming language is important because
it influences one's point of view. Our patterns assume Smalltalk/C++
language-level features, and that choice determines what can and cannot
be implemented easily. (Design Patterns, p.4)（程序设计语言的选择非常重要，它将影响人们理解问题的出发点。我们的设计模式采用了 Smalltalk 和 C++ 层的语言特性，这个选择实际上决定了哪些机制可以方便的实现。） |
不幸的是，这一点经常被忽略，程序员们经常把设计模式和方法混用。
Martin Fowler 解释了两者的不同：
| Recipes tend to be more particular, usually tied to a particular
programming language and platform. Even when patterns are tied to a
platform, they try to describe more general concepts.（方法依赖于特定的编程语言和平台使它更加的特殊。即使是当模式依赖于平台的时候，他们也只是去描述更加一般的概念。） |
如果你曾经看见一个看起来象C++方法集合的Java或者C#的应用程序，你就知道了混合这两个概念所产生的坏处了。不管你对模式和方法这两个概念之间的差异理解到何种程度，你所能想到的程序设计语言就只是你设计时所使用的程序语言。这也是Prags鼓励每一个人每年学习一门新的语言的一个原因。你可以结合你所知道的所有程序设计语言来进行设计，但至少你不是一个绝望的“乡下人”（？）。
编程语言的发展弱化了模式和方法之间的概念模糊。在1998年，Peter Norvig 辩驳道大部分的 GoF 模式在 Dylan 和 Lisp 中都看不到踪影或者非常简单的使用。在那以后，Greg Sullivan 也对 Scheme 做出相同的观点。Jan Hannemann 也指出 Java+AspectJ 也是如此。设计模式表现的不如方法那样好。他们至多平分秋色。
在编码层，大部分的设计模式都是有代码异味的。当程序员在 Review 代码的时候看到了一个设计模式，他们陷入了睡梦般的熟悉。醒醒吧！那是设计模式呢还是来自某种古老的语言的一种陈旧的方法？
http://www.blogjava.net/qujinlong123/