PrintJ的设计模式之旅——1.模式之父

好奇设计模式的源头,做了一番搜索和调查,于是便开启了这个系列“PrintJ的设计模式之旅”。

1.模式之父

GOF(Gang of Four)

Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides合著了"Design Patterns: Elements of Reusable Object-Oriented Software"(中文版《设计模式 : 可复用面向对象软件的基础》)

。这四位大神是公认的设计模式之父。

但是,大神们又是受到了谁的启发,基于什么动机去开始这项“伟业”呢是他们发明了设计模式还是发现了设计模式呢

带着这两个问题,找到了下面这位大神。

Christopher Alexander

C.亚历山大——加州大学伯克利分校建筑学教授,环境结构中心负责人,写了"The Timeless Way of Building : Way of Building"一书(中文版《建筑的永恒之道》)。正式这本书激发了软件行业对模式的思索。

亚历山大的问题

亚历山大要解决建筑设计问题。假设你要建一所大学,必须向学生和老师解释你的设计,

  • 否则建筑工人无法将你的设计变成精妙的建筑。
  • 没有设计师能够让工人知道所有他们应该了解的知识。

由于无法将设计向所有的参与者一一解释清楚,于是你会看到一个巨大的瓦砾堆。

“如何将设计的职责在一个大型组织中进行合理分配,与此同时保证整体设计的一致性与协调性?”

这个问题同样适用于软件开发。

亚历山大的答案

亚历山大提出了“模式语言”——涵盖设计决策的一组辞典。

"A Pattern Language : Towns, Buildings, Construction"(中文版《建筑模式语言(上下) : 城镇·建筑·构造》)

书中提到了超过250个示例,通过模式语言可以进行设计交流。所有的讨论都基于同样的基础,提升了设计通用性。

模式是什么?不是什么?

  • 模式不会告诉你如何设计
  • 模式会帮助你决定需要设计哪些内容
  • 你可以自己发明(make up)模式,只要它能够让设计变得更好

对GOF设计模式的争论

GOF的23种设计模式在当时无疑是一种巨大的进步,但同时也有一些局限,比如编程语言。于是产生了一些对设计模式的争论:

  • 一些设计模式在其他编程语言中已经提供了默认实现;
  • 你会在代码里看到GOF的书中示例被到处拷贝;
  • GOF设计模式无法灵活地运用……

这里不做口水式的争论,有兴趣的看官可以参考附录中的文章。

Jeff Atwood的建议

个人觉得Jeff Atwood的建议还是挺中肯的:

学习设计模式没有问题,但务必更加深入地读懂建筑模式语言。毕竟,思考比代码更重要。

题外话

看了这么多设计模式“负面”的内容一定会有所怀疑吧。让我们再回到GOF,Eric Gamma作为先驱参与了Eclipse的设计。

虽然Eclipse中,GOF23种设计模式的痕迹已不再清晰,但Eclipse的生机勃勃说明了“模式”未死。

下一篇,我会循着GOF的足迹,带着亚历山大的精神继续设计模式之旅。

附录

 

你可能感兴趣的:(print)