常用设计模式小结

现在你已经准备好迎接一个充满设计模式的崭新世界。 但是，在你打开所有的机会大门之前，我们需要告诉你一些即将在真实世界中遇到的细节–没错，外面的世界还是比较复杂的。来吧，接下来，我们会指引你的方向…

定义设计模式

在看完之前这么多章节的系列，相信作为读者的你已经基本了解什么是设计模式了。但我们至今还未给它一个正式的定义。我们先拿出一个常用的定义：

模式：是在某情境下，针对某问题的某种解决方案。

情境就是应用某个模式的情况。这应该是会不断出现的情况。（例如：你拥有一个对象的集合）
问题就是你想在某情境下达到的目标 ，但也可以是某情境下的约束。（你需要注意走访每个对象，而且不需理会该集合的实现）

解决方案就是你所追求的：一个通用的设计，用来解决约束、达到目标。（将迭代封装进分离的类中）

这是一个需要花些时间逐步理解的定义。在这里，我帮你们找到了一个记忆的方法：

“如果你发现自己处于某个情境下，面对着所欲达到的目标被一群约束影响着的问题，然后，你能够应用某个设计，克服这些约束并达到该目标，将你领向某个解决方案。”

组织设计模式

对着发掘的设计模式数目逐渐增加，有必要将他们分门别类，好将他们组织起来，以简化我们寻找模式的过程，并让同一群组内的模式互相比较。

我们感觉模式的目标分成三个不同类目：创建型、行为型和结构型。

小编先来引导下，这三个类型的基本定义。

创建型模式涉及到将对象实例化，这类模式都提供一个方法，将客户从所需要实例化的对象中解耦。

行为型模式涉及到类和对象如何交互及分配职责。

结构型模式可以让你把类或对象组合到更大的结构中。

现在有了基本的定义，请先停顿下，给自己几分钟时间来给设计模式分类，然后再看下面小编整理的分类。

创建型	行为型	结构型
单例（singleton）	模板方法（Template Method）	装饰（Decorator）
工厂(Factory Method)	命令（Command）	组合（Composite）
抽象工厂（Abstract Factory）	观察者（Observer）	适配器（Adapter）
建造者（Builder）	迭代器（Iterator）	代理（Proxy）
原型（Prototype）	状态（State）	外观（Facede）
	策略（Strategy）	享元（Flyweight）
	中介者（Mediator）	桥接（Bridge）
	访问者（Visitor）
	备忘录（Memento）
	解释器（Interpreter）
	责任链（Chain of Responsibility）

其中未加粗部分还没系统学习过，在稍后的章节，还会做一些简单的介绍。

除了刚才的分类之外 ，模式还有另一种分类方式：模式所处理的类或对象

类模式描述类之间的关系如何通过继承定义。类模式的关系是在编译时建立的。

对象模式描述对象之间的关系，而且主要是利用组合定义。对象模式的搞关系通常在运行时建立，而且更加动态、更有弹性。

类	对象
模板方法（Template Method）	单例（singleton）
工厂(Factory Method)	装饰（Decorator）
适配器（Adapter）	命令（Command）
解释器（Interpreter）	组合（Composite）
	抽象工厂（Abstract Factory）
	观察者（Observer）
	建造者（Builder）
	迭代器（Iterator）
	代理（Proxy）
	原型（Prototype）
	状态（State）
	外观（Facede）
	策略（Strategy）
	享元（Flyweight）
	中介者（Mediator）
	桥接（Bridge）
	访问者（Visitor）
	备忘录（Memento）
	责任链（Chain of Responsibility）

用模式思考问题

小编在这里根据书本，还整理了一份快速指南，可以帮助你开始“用模式思考”。所谓“用模式思考”，意思就是说，能够看着设计，体会在什么地方模式能自然适用，在什么地方模式则不能。

1. 保持简单

首先，当你设计时，尽可能地用最简单的方式解决问题。你的目标应该是简单，而不是“如何在这个问题中应用模式”。如果没有使用模式解决某个问题，千万不要以为你就不是一个经验丰富的开发人员。如果你能保持简单的设计，那岂不是更好，甚至你还能得到其他开发人员的欣赏和尊敬呢。

所以，正确的做法就是，为了要让你的设计简单而且有弹性，有时候使用模式是最好的办法，但不是每次都需要使用。

2. 设计模式非灵丹妙药

如果所知道的，模式是解决一再发生的问题的通用方案。模式已经被许多开发人员实际测试过。所以，当你需要某个模式的时候，可以放心地使用它，毕竟你知道这个模式已经身经百战。

然后，模式并非灵丹妙药。你需要考虑到模式对你的设计中其他部分所造成的后果。

3. 你知道何时需要模式

这是最重要的问题：何时使用模式？当你在设计的时候，如果确定在你的设计中可以利用某个模式解决某个问题，那么就是用这个模式！如果有更简单的解决方案，那么在决定是用模式之前应该先考虑这个方案。

如何知道何时是用一个模式，这就需要经验和知识了。一旦你确定一个简单的解决方案无法满足你的需要，应该考虑这个问题以及相关的约束–这可以帮你将问题对应到一个模式中。如果你对模式有很深的认知，就可能知道有什么模式适合这样的情况。否则，就花些时间调查一下可能会解决这个问题的模式，模式类目中的意图和应用部分会特别有用。

4. 拿掉你所不需要的

何时应该删除这个模式呢？当你的系统变得非常复杂，而且并不需要预留任何弹性的时候，就不要使用模式。换句话说，也就是当一个比较简单的解决方案比使用模式更好的时候，你就不需要使用。

5. 如果你现在不需要，就别做

如果你今天在设计中有实际的需要去支持改变，就放手采用模式处理这个改变。但是，如果说理由只是假想的，就不要添加这个模式，因为这只会将你的系统搞越复杂，而且很可能你永远都不会需要它。

最后，将模式和描述配对

在这篇文章的最后，还是给大家一个十足的干货，将之前所学的设计模式和描述进行配对，让你对这些常用的模式有一个更加深刻的印象，让你学习有成。

模式	描述
装饰者	包装一个对象，以提供新的行为
状态	封装了基于状态的行为，并使用委托在行为之间切换
迭代器	在对象的集合之中游走，而不暴露集合的实现
外观	简化一群类的接口
策略	封装可以互换的行为，并使用委托来决定要使用哪一个
代理	包装对象，以控制对此对象的访问
工厂方法	由子类决定要创建的具体类是哪一个
适配器	封装对象，并提供不同的接口
观察者	让对象能够在状态改变时被通知
模板方法	由子类决定如何实现一个算法中的步骤
组合	客户用一致的方式处理对象集合和单个对象
抽象工厂	允许客户创建对象的家族，而无需指定他们的具体类
命令	封装请求成为对象

小结

至此，《Head First 设计模式》一书，历时五个月，小编把书中详细介绍的模式基本都学习并输出了一遍。其中，第12章有个复合模式，讲述的是一个MVC使用设计模式的过程，小编还需要消化，也怕输出起来影响大家的学习，故就断了这个念头。

还有11章的代理模式，小编挑选了Hollis在博客上的文章来学习，力求能让大家看的更好，小编在此和大家道歉。很感谢，从头到尾一直和小编学习的读者，设计模式系列，还有最后几篇的输出，小编会继续努力，把这个系列用更好的方式完结。

「奔跑吧攻城狮」感谢大家的关注，现在后台回复「设计模式」赠你小编精心挑选设计模式书籍。小编最近开窍，组建了一个技术交流群，回复「加群」即可解锁。