设计模式区别（一）

最近一段时间一直在学习设计模式，我有一个感受就是：接触头几个设计模式时感觉似乎就那么一回事，好像没有什么可学习的，因为理解起来很简单，也很容易记忆，在例子的带动下似乎也有那么一点意思了，好像自己懂了。慢慢地，随着学习的深入，接触到了各种各样的设计模式，前面那种轻松的劲儿就没了，越学越迷糊，感觉很多模式好像都是类似的，自己也分不清和前面学的模式的区别是什么了。再后来，经过对这23种基本的设计模式仔细研究，对比其实现类图以及模式使用的目的，基本上清楚明白了各个设计模式之间的区别以及他们各自的使用范围，为了使和我一样在学习设计模式的朋友少一些迷惑，我将我认为的一些类似的、容易混淆的设计模式之间的区别总结出来共享给大家，希望能有所帮助，如有谬误，欢迎指正。

在进入正题之前，首先来了解一些基本的东西，有助于理解设计模式。

在面向对象编程中，理解对象、接口、类和继承子类的概念对大多数人来说并不困难，问题关键在于如何运用它们写出灵活的、可复用的软件，而设计模式则可以告诉你如何去做。

面向对象系统中功能复用最常用的技术是类继承和对象组合。类继承属于白盒复用，也就是说通过生成子类来达到复用的目的，父类的内部细节对子类可见；对象组合属于黑盒复用，对象的内部细节是不可见的，对象组合要求被组合的对象具有良好定义的接口。针对以上的复用技术，我们需要遵守两条原则：第一，针对接口编程，而不是针对实现编程；第二，优先使用对象组合，而不是类继承。

针对接口编程有两个好处：第一个好处是客户不需要知道他们使用的对象的特定类型 ，只须对象有客户所期望的接口；第二个好处是客户无须知道他们使用的对象是用什么类来实现的，他们只须知道定义的接口或者抽象类。这将极大的减少子系统实现之间的相互依赖关系。

优先使用对象组合的优点是：第一，由于对象的实现是基于接口编写的，所以在实现上存在较少的依赖关系，可以在运行时刻动态的替换引用的对象实现；第二，优先使用对象组合有助于保持每个类背封装，并被集中在单个任务上，这样类和类的继承层次会保持在较少的规模，并且不太可能增长为不可控制的庞然大物；第三，使用对象组合可以最大限度的不用创建新的构件，而使用已有的构件就可以组装获得所需要的功能。

设计模式就采用了大量的对象复合技术。设计模式按照目的划分，可以分为创建型、结构型、行为型三种，其中创建型模式与对象的创建有关，结构型模式处理类或对象的组合；行为型模式对类或对象怎样交互和怎样分配职责进行描述。

下面是各种模式按照目的划分的分类

创建型模式：Factory Method、Abstract Factory、Builder、Prototype、 Singleton

构造型模式：Adapter、Bridge、Composite、Decorator、Façade、Flyweight、
Proxy

行为型模式：Chain of Responsibility、Command、Iterator、Mediator、Mementor、Memento、Observer、State、Stategy、Visitor、Template Method、
Interpreter

<shapetype id="_x0000_t75" coordsize="21600,21600" stroked="f" filled="f" path="m@4@5l@4@11@9@11@9@5xe" o:preferrelative="t" o:spt="75"><font size="3"><font face="宋体"> <stroke joinstyle="miter"></stroke></font></font><formulas><f eqn="if lineDrawn pixelLineWidth 0"></f><f eqn="sum @0 1 0"></f><f eqn="sum 0 0 @1"></f><f eqn="prod @2 1 2"></f><f eqn="prod @3 21600 pixelWidth"></f><f eqn="prod @3 21600 pixelHeight"></f><f eqn="sum @0 0 1"></f><f eqn="prod @6 1 2"></f><f eqn="prod @7 21600 pixelWidth"></f><f eqn="sum @8 21600 0"></f><f eqn="prod @7 21600 pixelHeight"></f><f eqn="sum @10 21600 0"></f></formulas><path o:connecttype="rect" gradientshapeok="t" o:extrusionok="f"></path><lock aspectratio="t" v:ext="edit"></lock><shape id="_x0000_s1044" style="MARGIN-TOP: 69.05pt; Z-INDEX: 1; LEFT: 0px; MARGIN-LEFT: 94.5pt; WIDTH: 417pt; POSITION: absolute; HEIGHT: 267pt; TEXT-ALIGN: left; mso-position-horizontal-relative: text; mso-position-vertical-relative: text; mso-position-horizontal: absolute; mso-position-vertical: absolute" type="#_x0000_t75"><imagedata o:title="" src="file:///C:%5CDOCUME~1%5CADMINI~1%5CLOCALS~1%5CTemp%5Cmsohtml1%5C01%5Cclip_image001.png"></imagedata><wrap type="square"></wrap></shape><stroke joinstyle="miter"></stroke><formulas><f eqn="if lineDrawn pixelLineWidth 0"></f><f eqn="sum @0 1 0"></f><f eqn="sum 0 0 @1"></f><f eqn="prod @2 1 2"></f><f eqn="prod @3 21600 pixelWidth"></f><f eqn="prod @3 21600 pixelHeight"></f><f eqn="sum @0 0 1"></f><f eqn="prod @6 1 2"></f><f eqn="prod @7 21600 pixelWidth"></f><f eqn="sum @8 21600 0"></f><f eqn="prod @7 21600 pixelHeight"></f><f eqn="sum @10 21600 0"></f></formulas><path o:connecttype="rect" gradientshapeok="t" o:extrusionok="f"></path><lock aspectratio="t" v:ext="edit"></lock></shapetype><shape id="_x0000_i1025" style="WIDTH: 417pt; HEIGHT: 267pt" type="#_x0000_t75"><imagedata o:title="" src="file:///C:%5CDOCUME~1%5CADMINI~1%5CLOCALS~1%5CTemp%5Cmsohtml1%5C01%5Cclip_image001.png"></imagedata></shape>

<shapetype id="_x0000_t75" coordsize="21600,21600" stroked="f" filled="f" path="m@4@5l@4@11@9@11@9@5xe" o:preferrelative="t" o:spt="75"><stroke joinstyle="miter"></stroke><formulas><f eqn="if lineDrawn pixelLineWidth 0"></f><f eqn="sum @0 1 0"></f><f eqn="sum 0 0 @1"></f><f eqn="prod @2 1 2"></f><f eqn="prod @3 21600 pixelWidth"></f><f eqn="prod @3 21600 pixelHeight"></f><f eqn="sum @0 0 1"></f><f eqn="prod @6 1 2"></f><f eqn="prod @7 21600 pixelWidth"></f><f eqn="sum @8 21600 0"></f><f eqn="prod @7 21600 pixelHeight"></f><f eqn="sum @10 21600 0"></f></formulas><path o:connecttype="rect" gradientshapeok="t" o:extrusionok="f"></path><lock aspectratio="t" v:ext="edit"></lock></shapetype><shape id="_x0000_i1025" style="WIDTH: 417pt; HEIGHT: 267pt" type="#_x0000_t75"><imagedata o:title="" src="file:///C:%5CDOCUME~1%5CADMINI~1%5CLOCALS~1%5CTemp%5Cmsohtml1%5C01%5Cclip_image001.png"></imagedata></shape>

创建型模式之间的区别

GoF23种设计模式中创建型模式有5种，分别是：Singleton单件模式、Abstract Factory抽象工厂模式、Builder生成器模式、Factory Method工厂方法模式、Prototype原形模式。由于创建型模式与对象创建有关，所以这几种模式一般不会与其他的结构型模式和行为型模式混淆，这里将创建型模式单独列出来集中讲解。下面分别总结这几种设计模式。

设计模式	GoF的描述	优点或缺点
Singleton单件模式	保证一个类仅有一个实例，并提供一个该实例全局的访问点	可以保证唯一实例；允许在需要时拥有可变数目的实例
Abstract Factory抽象工厂模式	提供一个接口，让该接口负责创建一系列“相关或者相互依赖的对象”，无需指定他们的具体类	分离了具体的类；可以生产一系列的相关对象，有利于产品的一致性；缺点是难以支持新种类的产品
Builder生成器模式	将一个复杂对象的构建与其表示向分离，使得同样的构建过程可以创建不同的表示	可以使你改变一个产品的内部表示；将构造过程和表示分开；可以对构造过程进行更精细的控制
Factory Method工厂方法模式	定义一个用于创建对象的接口，让子类决定实例化那个类。FactoryMethod使得一个类的实例化延迟到子类	为子类提供了挂钩以提供对象的扩展版本，也就是说子类可以覆盖工厂方法改变创造的产品实例
Prototype原形模式	使用原型实例指定创建对象的种类，然后通过拷贝这些原型来创建新的对象	改变值获得新的对象；可以在运行时刻指定要实例化的类，例如某个对象设置了若干属性之后，我们需要N这种设置了相同属性的对象，那么可以通过该模式，在动态运行时直接拷贝来生成

这里容易混淆的是Abstract Factory模式和Builder模式，Factory Method模式和Prototype模式也不好区分。Singleton模式没什么太大的困难。下面就来分析一下前四种模式。

一、Abstract Factory模式和Builder模式：

Abstract Factory是应对一系列对象的创建的问题，对于创建一个汽车对象来说，Abstract Factory模式更关注一系列的对象的创建，如：Wheel、Engine、Body等等类型的创建, 这里的一系列可以这样理解，宝马汽车需要宝马的Wheel，宝马的Engine，宝马的Body等等一系列配套的东西，而保时捷汽车则需要保时捷的Wheel，保时捷的Engine等等和保时捷配套的东西。大家注意这换句话说关注点在这一系列对象上，同时它关注创建对象得到的结果。

Builder则是将复杂对象的构建过程与它的表示相分离，使得不同的表示可以使用同样的构建过程。这里我们要注意红色的部分，即构建过程与表示相分离，我们可以如此理解，也就是说将结果与对象创建过程进行分离，这里关注点是过程。Builder模式注重的对象生产的过程，也就是如何一步一步将需要的对象构建起来的，同样对于一个汽车对象来举例，我们需要首先创建Wheel，再创建Engine,再创建Body，然后将他们进行组装，得到想要的汽车对象，可以看到，Builder模式将构建的组装的过程进行了隐藏和封装。而Abstract Factory则只是一系列对象的工厂，组装可能还是需要客户自己来完成。

二、Factory Method模式和Prototype模式：

这两个模式区别比较简单，可以这样理解，Factory Method模式是重新创建一个对象；Prototype模式是利用现有的对象进行克隆，当两个对象或多个对象雷同的时候，可以考虑用一个已创建的对象去克隆出其余的对象。

Abstract Factory一般是利用Factory Method模式来完成一系列对象中的单个对象的创建。

未完待续