好奇设计模式的源头，做了一番搜索和调查，于是便开启了这个系列“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
是如何计算的)
