很老的文章,在网上偶然看到,转自:http://www.infoq.com/cn/news/2007/08/GoFCriticism
十多年前,被人称之为“四人帮(Gang of Four,GoF)”的Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides出版了他们这本划时代的著作:“设计模式:可复用面向对象软件的基础”。这本书曾被认为是整个软件模式发展的先驱,但最近却被人质疑已经与时代的发展脱节,书中解决问题的方式已经可以由新的语言来更好的处理,而且还增加了不必要的复杂度。
这一切都是由7月的早些时候,Jeff Atwood(Code Horror)对GoF的这本设计模式进行批评而引起的。Jeff说道,虽然他认为每一个程序员都应该读一下这本书,但是他仍然认为书中存在两个很大的问题:
1. 设计模式是复杂性的一种表现形式。我宁愿看到开发者在直接拿一张复杂的设计模式处方来用之前,先把注意力集中在寻找更简单的解决方案上。
2. 如果你发现自己常常需要写上一大堆设计模式的样板式代码(boilerplate code)来处理“经常重现的设计问题”,那设计思路本身就是有问题的——这也是一个表示你所使用的语言的基础结构出现问题的信号。
Jeff还在文中引用了Mark Dominus的话。Mark的看法是GoF的设计模式一书实际上阻碍了Christoper Alexander等人思想的传播——他们编写了“A Pattern Language - Towns, Buildings, Construction”这本描述建筑架构的著作,该书被公认为激发了计算机科学领域内的设计模式运动。
Steve Rowe也认为模式应当被作为优秀设计和原则的示例加以应用,而不是被当作一本参考书来翻阅,但是他同时也指出Jeff的说法是偏离主题的,因为Jeff指责的不是人们错误的应用设计模式的方式,而是设计模式的概念。他最后总结说,模式应当被当作优秀设计的示例,而非教条:
当我们学习设计模式发挥作用的方式来帮助我们创建相似的模式时,设计模式是好的;但是当我们直接把它们拷贝过来用时,它们就是坏的。如果有人翻开GoF的书,他就会发现作者常常都会为每一种设计模式都给出一些略有不同的示例。而且他或许也会发现在书中有大量的关于OO的讨论,这些讨论最终的结果就是模式。
Cedric Beust(Otaku)在一篇名为“为设计模式而辩(In Defense of Design Patterns)” 的文章中对Jeff和Mark的批判做出了回应。Cedric认为Jeff(以及在他之前的Mark)对GoF一书进行批判但没有给出替代方案的做法是错误的。还有一个问题就是把Alexander的建筑设计模式和软件设计模式放在一个层面上比较:
很明显,我们应当把Alexander的设计模式和GoF的设计模式分离开来,其原因在于:软件工程的发展要远远落后于建筑工程。我们目前还只是处于做一些螺母和螺栓的阶段,无论什么时候启动一个新的软件项目,我们都不能保证一年之后它不会因为自身的重量而垮掉。换个视角来看,我们不妨想像一下这样一个世界:当一个建筑(比如说一座大桥)开工时,这个项目中雇用了什么样的工程师和工人,这座桥就会有什么样的未来……
Cedric说,建筑的发展要比软件领先的多(在可预测性和稳定性方面)。我们现在还是在地基上努力奋斗,我们也应该把精力集中在这里。
Aristotle Pagaltzis却在Cedric的博客上留言表示Mark的看法是有理有据的:
Dominus的意思是可以把设计模式看作是一个信号,它表示了一门语言在设计模式所用来解决问题的领域内的欠缺。换句话说,在Java中用到的访问者(Visitor)模式就说明了Java在访问列表方面的不足:“Map”和“Filter”这样的语言构造不得不使用冗长的面向对象咒语才能模拟出来。
他 不是说 像这样用设计模式不对。他只是说它们表示了语言的不足。
看上去大多数人(如果不是全部的话)都认为设计模式作为软件工程的工具是很有用处的,人们的分歧只是聚焦于GoF的书在今天的价值而已。你的意见是什么?你觉得GoF的设计模式是永不褪色的珍宝,还是已成明日黄花?
查看英文原文:Gang of Four Design Patterns - Does it stand the test of time?