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)。当程序员在代码检查中看到了设计模式，他们就会滑入到催眠般的熟悉场景中。醒醒！那是一个设计模式，或者说是一个来自腐臭程序语言的失效药方？