设计模式的局限性与适用性

4 years ago

source link: https://blog.csdn.net/lovelion/article/details/12167069
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

设计模式的局限性与适用性

LoveLion 2013-09-29 16:14:44 5072

《设计模式》的出版，是软件开发领域的一个关键转折点。设计模式理论的出现，让我们对软件的关注点，从如何在特定语言中实现最好的算法，提升为如何在特定环境下找到特定软件问题的最佳解决办法。这个转变不是一夜完成的，因为在这本书诞生前，软件模式运动已经进行多年。但这本书引领我们超越了在代码重用上的争议，上升到设计重用的高度；这本书第一次明确宣布了模式时代的到来。

审读此书手稿时，我感到非常震撼——它使用的抽象手法是如此轻易，而又清晰地描述了设计模式。对开发者来说，不再需要就算法、基于特定语言的对象构造、循环或条件争得面红耳赤，而可以用Visitor或Flyweight这样简洁的模式名一下子将原来需要几页纸才能说清楚的实现细节、设想、限制和适用性准确定义。团队成员间的有效沟通，无疑是软件开发的一个要素，设计模式恰能在这里起到重要作用，有了它，开发者可以在比以往高得多的抽象层面上实现准确、清晰沟通。

我当时最感兴趣的是Visitor模式。那时候我一直在从事后端编译器开发工作，读完手稿后，我马上根据Visitor模式重构了代码。重构后的编译器变得更为灵活、易于扩展和维护，队友理解也容易多了。而Chain of Responsibility则一直是我的最爱，因为它非常适用于我过去20年一直从事的分布式系统和中间件工作。我在不少系统中成功使用了这个模式。和其他很多模式一样，第一次听到Chain of Responsibility时，你不会有什么特别感觉。而我这么多年已经看到太多脆弱而笨拙的分布式系统了，如果他们的设计者运用这个模式，完全可以避免这些问题。

当然，设计模式本身有其适用范围，这是我们不得不考虑的。过去10年，Erlang和Haskell等函数式编程(FP)语言引起了越来越多人的兴趣。而一些著名的FP语言程序员甚至公开宣称：《设计模式》讲的模式并不适用于FP。我自己已经从OOP转到FP，因此非常同意这种观点。《设计模式》的关注点在OOP，确实不太适合FP语言。此外，设计模式本身已在FP中长期存在，绝大多数时候，它们本身就已经是这种语言的一个组成部分了。

局限性和适用性，本身就是设计模式的一个部分。懂得这些模式，就意味着我们不仅要知道什么时候该用，也要知道什么时候不该用。作为2009年的软件从业者，我们可以很轻松接受这个事实了吧。

【本文转自《程序员》2009年12月刊特别专题：设计模式15年】

文/Steve Vinoski 译/罗小平

作者简介：Steve Vinoski，《Design Patterns》的审稿人。著名中间件技术专家，他被公认为是CORBA领域里世界领先的专家之一，《IEEE Internet Computing》专栏作家，是《Advanced CORBA Programming with C++》【中译名：《基于C++ CORBA高级编程》】一书的作者之一。

Blog: http://steve.vinoski.net/blog/

20130929161006328