這是一篇譯文,你可以參看本文在TSS上的 英文原文,這是我的第一篇譯文,有很多不當之處請見諒,若能指出則更好了。
在GoF的設計模式那本書中作者清楚的指出在使用設計模式的時候所使用的語言是非常重要的:
不幸的是,這一點經常被忽略,程序員們經常把設計模式和方法混用。Martin Fowler 解釋了兩者的不同:
如果你曾經看見一個看起來象C++方法集合的Java或者C#的應用程序,你就知道了混合這兩個概念所產生的壞處了。不管你對模式和方法這兩個概念之間的差異理解到何種程度,你所能想到的程序設計語言就只是你設計時所使用的程序語言。這也是Prags鼓勵每一個人每年學習一門新的語言的一個原因。你可以結合你所知道的所有程序設計語言來進行設計,但至少你不是一個絕望的“鄉下人”(?)。
編程語言的發展弱化了模式和方法之間的概念模糊。在1998年,Peter Norvig 辯駁道大部分的 GoF 模式在 Dylan 和 Lisp 中都看不到蹤影或者非常簡單的使用。在那以后,Greg Sullivan 也對 Scheme 做出相同的觀點。Jan Hannemann 也指出 Java+AspectJ 也是如此。設計模式表現的不如方法那樣好。他們至多平分秋色。
在編碼層,大部分的設計模式都是有代碼異味的。當程序員在 Review 代碼的時候看到了一個設計模式,他們陷入了睡夢般的熟悉。醒醒吧!那是設計模式呢還是來自某種古老的語言的一種陳舊的方法?
http://www.aygfsteel.com/qujinlong123/
在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.aygfsteel.com/qujinlong123/