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的足迹，带着亚历山大的精神继续设计模式之旅。

附录

• DESIGN PATTERNS CRITICISM
• Rethinking Design Patterns
• "Design Patterns" Aren't

• Design Patterns: When Breaking The Rules Is OK