被误读的设计模式

1994年10月21日，有四个哥们儿出版了一本书，名字叫做《设计模式：可复用面向对象软件的基础》（Design Patterns: Elements of Reusable Object-Oriented Software）。

这四个哥们儿后来以“四人帮”（Gang of Four，GoF）著称，而他们的《设计模式：可复用面向对象软件的基础》一书也就成为了 设计模式 的开山之作。

对设计模式的误解

笔者之前发布了几篇介绍设计模式的的博客，看到有的读者对设计模式的评论是：

• 看了也不会，会了也不用
• 设计模式有使用场景的，不能生搬硬套
• 我写了那么多年代码，从来没用过设计模式

关于使用设计模式的3个问题

这里我不得不说，大家对设计模式是有很多误解的，面对设计模式我们至少要思考下面3个问题：

• 首先，什么是设计模式？

设计模式简而言之就是 一些常见软件设计问题的标准解决方案 。

正如设计模式的开山之作《设计模式：可复用面向对象软件的基础》一书中所说的那样：

可复用

可以说，如果问题是我们的敌人，代码是我们的剑，设计模式就是高手心中的剑谱。

• 接着，怎么使用设计模式

《Head First 设计模式》 一书的作者里曼说，使用设计模式有3个层次：

• Beginner —— 初级选手，在编程的时候无处不用设计模式，认为用的模式越多设计就越好。

• Intermediate —— 中级选手，在编程的时候知道何时该用什么设计模式，而什么时候不该用。

• Zen —— 到了禅的境界，“他山之石，可以攻玉”。设计模式被用来简化设计，让设计更优雅。

非要把设计模式硬塞到设计之中，那只是初级菜鸟的层次。

• 最后，设计模式在实际生产中使用的多不多？

设计模式本身就是源自实际问题的优秀解决方案的总结，因此在很多基础的架构和框架里，都可以看到设计模式的影子。

比如 Java 开发者经常使用的Spring框架，从创建型的工厂模式、单例模式、原型模式，再到结构型的享元模式、代理模式，再到行为型的观察者模式、模板模式，在其源码中随处可见。

无处不在的设计模式

设计模式不是空中楼阁，也不是只有面试和吹牛的时候才能放在嘴边的炫耀资本，而是一个优秀的开发者可以让自己的设计更加优雅的不可或缺的好帮手。

并且设计模式也并不是软件行业特有的现象，很多行业中有经验的从业者都会使用各种“模式”来优化自己的设计。

就拿剧本创作举例，如果一个剧作家要写一个剧本，并不是完全凭空创建的，也有各种业内普遍应用的模式，例如“悲剧英雄模式”(《麦克白》、《哈姆雷特》)、“凄美爱情模式”(《罗密欧与朱丽叶》、《梁山伯与祝英台》)等等，都是剧作家可以使用的“设计模式”。

如何解释设计模式

一般而言，要介绍一个设计模式，至少要包含如下4个要素：

1. 问题(Problem)

描述了我们遇到了哪些问题，也就是某个设计模式的使用场景。

2. 解决方案(Solution)

为了解决上面遇到的问题，我们想到了哪些解决方案。其中最具有普遍性的方案往往就是我们的设计模式的内容。

3. 效果(Consequence)

设计模式就像一个模板，可以为解决不同的问题提供思路。而解决问题的效果就是衡量一个设计模式在某个场景下是否适合的关键因素，一般我们要衡量的方面有灵活性、可移植性、可扩充性、性能等。

4. 模式名称(Pattern Name)

一个好的名字，可以让我们记住某个模式，并且可以望名知意，使其更便于传播。甚至作为我们思维方式的一部分保留下来。

以上面4个要素为基础，我们解释设计模式可以分为如下几个方面：

• 模式名称：模式的名字
• 模式别名：模式的其他名字或者昵称
• 模式分类：模式属于那种类型
• 模式意图：回答模式是干什么的，为了解决什么问题等问题
• 模式结构：模式包含哪些角色，以及这些角色之间的关系
• 模式适用性：哪些场景适合使用该模式
• 模式实现：通过例子来展示模式的实现过程
• 已知应用：该模式已经被使用在了什么地方
• 相关模式：模式中用到的模式，与该模式有替代关系的模式

发布/订阅模式 和 事件驱动模型 从原理到实战的系列文章：