這是一篇譯文，你可以參看本文在TSS上的
英文原文，這是我的第一篇譯文，有很多不當之處請見諒，若能指出則更好了。
在GoF的設(shè)計模式那本書中作者清楚的指出在使用設(shè)計模式的時候所使用的語言是非常重要的：
| 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)（程序設(shè)計語言的選擇非常重要，它將影響人們理解問題的出發(fā)點。我們的設(shè)計模式采用了 Smalltalk 和 C++ 層的語言特性，這個選擇實際上決定了哪些機制可以方便的實現(xiàn)。） |
不幸的是，這一點經(jīng)常被忽略，程序員們經(jīng)常把設(shè)計模式和方法混用。
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.（方法依賴于特定的編程語言和平臺使它更加的特殊。即使是當模式依賴于平臺的時候，他們也只是去描述更加一般的概念。） |
如果你曾經(jīng)看見一個看起來象C++方法集合的Java或者C#的應(yīng)用程序，你就知道了混合這兩個概念所產(chǎn)生的壞處了。不管你對模式和方法這兩個概念之間的差異理解到何種程度，你所能想到的程序設(shè)計語言就只是你設(shè)計時所使用的程序語言。這也是Prags鼓勵每一個人每年學習一門新的語言的一個原因。你可以結(jié)合你所知道的所有程序設(shè)計語言來進行設(shè)計，但至少你不是一個絕望的“鄉(xiāng)下人”（？）。
編程語言的發(fā)展弱化了模式和方法之間的概念模糊。在1998年，Peter Norvig 辯駁道大部分的 GoF 模式在 Dylan 和 Lisp 中都看不到蹤影或者非常簡單的使用。在那以后，Greg Sullivan 也對 Scheme 做出相同的觀點。Jan Hannemann 也指出 Java+AspectJ 也是如此。設(shè)計模式表現(xiàn)的不如方法那樣好。他們至多平分秋色。
在編碼層，大部分的設(shè)計模式都是有代碼異味的。當程序員在 Review 代碼的時候看到了一個設(shè)計模式，他們陷入了睡夢般的熟悉。醒醒吧！那是設(shè)計模式呢還是來自某種古老的語言的一種陳舊的方法？
http://m.tkk7.com/qujinlong123/