写点什么

“四人帮”的设计模式经得起时间的考验么?

  • 2007-08-04
  • 本文字数:1557 字

    阅读完需:约 5 分钟

十多年前,被人称之为“四人帮(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?

2007-08-04 11:005805
用户头像

发布了 197 篇内容, 共 54.4 次阅读, 收获喜欢 20 次。

关注

评论

发布
暂无评论
发现更多内容

自省与反思(一)

懒时小窝

反思 反思总结

简析Web3 架构:前端、后端和数据

devpoint

区块链 dapp Solidity Web3.0 2月月更

《人月神话》第十九章阅读笔记:20年后的《人月神话》

panda

人月神话 概念完整性 阅读笔记

基于 SAP BTP 平台的 AI 项目经验分享 | 社区征文

汪子熙

人工智能 机器学习 AI 新春征文 2月月更

Go 语言入门很简单:String

宇宙之一粟

Go 语言 2月月更

蜜罐中利用jsonp跨域漏洞和xss漏洞的分析

H

网络安全 安全漏洞

模块 7 作业

miliving

微信朋友圈高性能复杂度分析

「架构实战营」

iOS开发·备战2022金三银四-runtime原理与实践: 消息转发详解篇

iOSer

ios runtime iOS面试 ios开发 金三银四跳槽

iOS开发备战金三银四·突击大厂的算法与底层原理复习方向

iOSer

ios iOS面试 iOS底层 金三银四跳槽 算法面试

跨平台应用开发进阶(三): uni-app 实现资源在线升级/热更新

No Silver Bullet

uni-app 更新 版本升级 2月月更

给 zsh 自定义命令添加参数自动补全

mzlogin

Shell zsh

华为云IoT体验:基于IoT平台构建智慧路灯应用

乌龟哥哥

2月月更

项目遇到突发问题,如何给上级做汇报?

石云升

项目管理 项目经理 2月月更

架构实战营模块二作业-微信朋友圈复杂度分析

炎彬

「架构实战营」

渗透利器 | 常见的WebShell管理工具

喀拉峻

网络安全

模块二作业

blazar

「架构实战营」

深入浅出 ESM 模块 和 CommonJS 模块

局外人

JavaScript node.js 前端 前端开发 模块化

Web Components 系列—— 详解 Slots

CRMEB

跨平台移动APP开发进阶(一):mui开发注意事项

No Silver Bullet

App 跨平台 2月月更 mui

[架构实战营] 模块九作业

Geek_0ed632

「架构实战营」

springboot druid 数据库连接池连接失败后一直重连

Jeremy Lai

微信朋友圈业务架构分析

Geek_1b4338

#架构实战营 「架构实战营」

无人管的 InfoQ 每周精选

scruel

InfoQ

Web Components 系列(五)—— 详解 Slots

编程三昧

前端 组件化 2月月更 WebComponent

程序员,如何避免无效会议?

蜜糖的代码注释

2月月更

第十节:SpringBoot中的日志管理

入门小站

spring-boot

在线ASCII Banner艺术字生成工具

入门小站

工具

验收测试驱动开发后记

Bruce Talk

敏捷 Agile User Story

DevOps进阶(二):DevOps 发展史

No Silver Bullet

DevOps 2月月更

如何快速开发 Serverless Devs Package ?

Serverless Devs

Serverless

“四人帮”的设计模式经得起时间的考验么?_架构_Arnon Rotem-Gal-Oz_InfoQ精选文章