本文主要是介绍设计模式的局限性与适用性,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
《设计模式》的出版,是软件开发领域的一个关键转折点。设计模式理论的出现,让我们对软件的关注点,从如何在特定语言中实现最好的算法,提升为如何在特定环境下找到特定软件问题的最佳解决办法。这个转变不是一夜完成的,因为在这本书诞生前,软件模式运动已经进行多年。但这本书引领我们超越了在代码重用上的争议,上升到设计重用的高度;这本书第一次明确宣布了模式时代的到来。
审读此书手稿时,我感到非常震撼——它使用的抽象手法是如此轻易,而又清晰地描述了设计模式。对开发者来说,不再需要就算法、基于特定语言的对象构造、循环或条件争得面红耳赤,而可以用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/
【作者:刘伟 http://blog.csdn.net/lovelion】
这篇关于设计模式的局限性与适用性的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!