《设计模式》的出版，是软件开发领域的一个关键转折点。设计模式理论的出现，让我们对软件的关注点，从如何在特定语言中实现最好的算法，提升为如何在特定环境下找到特定软件问题的最佳解决办法。这个转变不是一夜完成的，因为在这本书诞生前，软件模式运动已经进行多年。但这本书引领我们超越了在代码重用上的争议，上升到设计重用的高度；这本书第一次明确宣布了模式时代的到来。
审读此书手稿时，我感到非常震撼——它使用的抽象手法是如此轻易，而又清晰地描述了设计模式。对开发者来说，不再需要就算法、基于特定语言的对象构造、循环或条件争得面红耳赤，而可以用Visitor或Flyweight这样简洁的模式名一下子将原来需要几页纸才能说清楚的实现细节、设想、限制和适用性准确定义。团队成员间的有效沟通，无疑是软件开发的一个要素，设计模式恰能在这里起到重要作用，有了它，开发者可以在比以往高得多的抽象层面上实现准确、清晰沟通。
我当时最感兴趣的是Visitor模式。那时候我一直在从事后端编译器开发工作，读完手稿后，我马上根据Visitor模式重构了代码。重构后的编译器变得更为灵活、易于扩展和维护，队友理解也容易多了。而Chain of Responsibility则一直是我的最爱，因为它非常适用于我过去20年一直从事的分布式系统和中间件工作。我在不少系统中成功使用了这个模式。和其他很多模式一样，第一次听到Chain of Responsibility时，你不会有什么特别感觉。而我这么多年已经看到太多脆弱而笨拙的分布式系统了，如果他们的设计者运用这个模式，完全可以避免这些问题。
当然，设计模式本身有其适用范围，这是我们不得不考虑的。过去10年，Erlang和Haskell等函数式编程(FP)语言引起了越来越多人的兴趣。而一些著名的FP语言程序员甚至公开宣称：《设计模式》讲的模式并不适用于FP。我自己已经从OOP转到FP，因此非常同意这种观点。《设计模式》的关注点在OOP，确实不太适合FP语言。此外，设计模式本身已在FP中长期存在，绝大多数时候，它们本身就已经是这种语言的一个组成部分了。
局限性和适用性，本身就是设计模式的一个部分。懂得这些模式，就意味着我们不仅要知道什么时候该用，也要知道什么时候不该用。作为2009年的软件从业者，我们可以很轻松接受这个事实了吧。
文/Steve Vinoski 译/罗小平
Blog: http://steve.vinoski.net/blog/
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！