Design Patterns are Code Smells
上個月就在TheSeverSide中看到關于這篇文章(實際是一篇簡短的Blog)的消息，當時就覺得很有趣，因為自己正在學習設計模式，故將這篇短文保存了下來。昨天在自己電腦中又看到了此文，順手就把它翻譯了出來。
這篇Blog的作者認為大部分設計模式在代碼層都是code smell，在文末評論中有Google Guice項目的leader -- Bob Lee的評語。Bob對作者的觀點表示了贊同，但也指出框架可以減輕對模式的需要。(2007.06.04最后更新)
在原始的Gof的書中，作者清楚地指出當你在使用設計模式時，
程序設計語言的選擇是重要的，因為它會影響某人的觀點。我們的模式假設是使用Smalltalk/C++語言級特性，這種選擇決定了什么容易/不容易實現(Design Patterns, p.4)。
不幸的是，這條信息基本上被丟棄了，程序員們時常將模式當作處方。Martin Fowler解釋了區別：
處方趨于更加特別，經常關聯于一個特別的語言和平臺。甚至當一些模式需要依賴一個特定的平臺時，他們仍試圖于用這些模式去解釋更加一般的概念。
如果你已經遇到一個Java或C#應用程序看起來像C++的處理方式，你就會知道這兩個概念的混合將造成損害。
不管你如何從處方中區分出模式，你所思考的程序設計語言就是你要為之所設計的程序語言。這也就是為什么Prags鼓勵每個人每年學習一種新的語言。你將仍會為你所知道的這組語言進行設計，但至少你將不會沒有希望。
程序語言提前使模式不能成為藥方。回到1998年，Petter Norvig爭論道，大部分的原始Gof模式在Dylan或Lisp中都是無形或簡單的。之后，Greg Sullivan對Scheme持同樣的觀點。Jan Hannemann也使用Java+AspectJ證明了相同的觀點。設計模式不能如處方那樣發揮良好。它們最多是周期性的。
在代碼級別，大部分的設計模式都是代碼異味(code smells)。當程序員在代碼檢查中看到了設計模式，他們就會滑入到催眠般的熟悉場景中。醒醒！那是一個設計模式，或者說是一個來自腐臭程序語言的失效藥方？