设计模式 （2）-设计模式的分类和区别

设计模式按照目的划分

可以分为创建型、结构型、行为型三种，其中创建型模式与对象的创建有关，结构型模式处理类或对象的组合；行为型模式对类或对象怎样交互和怎样分配职责进行描述。

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

• 创建型模式：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

创建型模式之间的区别

设计模式

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模式来完成一系列对象中的单个对象的创建。

*********************************************************************************************************************************************************

一、创建性模式

通过该类的子类来创建对象的。但是，这可能会限制在系统内创建对象的类型或数目

1、Abstract Factory 模式
在不指定具体类的情况下，为创建一些列相关或相互依赖的对象提供了接口。
提供了一个可以确定合适的具体类的抽象类。
优点：
可以与具体类分开。
更容易在产品系列中转换。
提高了产品间的一致性。
以下情况应该使用Abstract Factory 模式：
系统独立于产品的创建、组成、表示。
系统配置成具有多个产品的系列。
相关产品对象系列是共同使用的，而且必须确保这一点。
你希望提供产品的类库，只开放其接口。

2、Builder 模式
将复杂对象的构件与表示相分离，相同的构造过程可以创建不同的对象，通过只指定对象
的类型和内容。
一次就可以创建所有的复杂对象，而其他模式一次就只能创建一个对象。
优点：

可以对产品内部表示进行改变。
将构造代码与表示代码相分离。
以下情况应该使用Builder 模式：
算法独立于组成对象。
构造过程必须允许已构件对象有不同表示。
3、Factory Method 模式
实例化工作交给其子类，可以在不修改代码的情况下引入新类，因为新类只实现了接口。
优点：
代码只处理接口，因此可以使用任何实现了接口的类。
在类中创建对象比直接在客户端创建要更加灵活。
以下情况中，应该使用Factory Method 模式：
类不能预料它必须创建的对象的类。
类希望其子类指定要创建的对象。
类将责任转给某个帮助子类，而用户希望定位那个被授权的帮助子类。
4、Prototype 模式
只要将对象类定义成能够复制自身就可以实现。
优点如下：
可以在运行时添加或删除产品。
通过改变值指定新对象。
通过改变结构制定新对象。
减少子类的生成和使用。
可以用类动态地配置应用程序。
以下情况中，应该使用Prototype 模式：
运行时，指定需要实例化的类，例如动态载入。
避免构建与产品的类层次结构相似的工厂类层次结构。
5、Singleton 模式
确保一个类只有一个实例，并且提供全局访问入口，确保使用这个实例所有的对象使用
相同的实例。
优点：

对单个实例的受控访问。
命名空间的减少。
允许改进操作和表示。
允许改变数目的实例。
比类操作更灵活。

 

二、结构性模式

机构性模式控制较大部分之间的关系。
它将以不同的方式影响应用程序。
允许在补充写代码或自定义代码的情况下创建系统。
具有增强的重复使用性和应用性能。
1、Adapter 模式
可以充当两个类之间的媒介，可以转换一个类的接口，被另外一个类使用，使得具有不兼容
接口的类能够系统使用。
优点：
允许多个不兼容的对象进行交互和通信。
提高已有功能的重复使用性。
以下情况，应该使用Adapter 模式：
要使用已有类，而该类接口与所需的接口并不匹配。
要创建可重用的类，该类可以与不相关或未知类进行协作。
要在一个不同于已知对象接口的接口环境中使用对象。
必须要进行多个源之间的接口转换的时候。
2、Bridge 模式
将一个复杂的组件分成两个独立的但又相关的继承层次结构：功能性抽象和内部实现。
优点：
接口与实现相分离。
提高了可扩展性。
对客户端隐藏了实现的细节。

以下情况中，应该使用Bridge 模式：
避免在抽象及其实现之间存在永久的绑定。
抽象及其实现可以使用子类进行扩展。
抽象的实现被改动不用重新编译代码。
3、Composite 模式
创建树形层次结构来改变复杂性。
优点：
定义了由主要对象和符合对象组成的类层次结构。
添加新的组件类型更加简单。
结构的灵活性和可管理性的接口。
以下情况中，应该使用Composite 模式：
想要表示对象的整个或者部分的层次结构。
想要客户端能够忽略符合对象和单个对象之间的差异。
结构可以具有任何级别的复杂性，而且是动态的。
4、Decorator 模式
不修改对象外观和功能的情况下添加或删除对象功能。
优点：
比静态继承具有更大的灵活性。
避免了特征装载的类处于层次结构的过高级别。
简化了编码。
改进了对象的扩展性。
在以下情况中，应该使用Decorator 模式：
在单个对象中动态并且透明地添加责任，不会影响其他对象。
以后可能要修改的对象中添加责任。
无法通过静态子类化实现扩展时。
5、Facade 模式
为子系统中的一组接口提供了一个统一的接口。更容易使用子系统的高级接口。
优点：
在不减少系统所提供的选项的情况下，为复杂系统提供了简单接口。

屏蔽了子系统组件。
提高若耦合度。
将客户端请求转换后发送给能够处理这些请求的子系统。
以下情况中，应使用Facade 模式：
为复杂的子系统提供简单的接口。
客户端和抽象的实现类中存在许多依赖关系。
想要对子系统进行分层。
6、Flyweight 模式
通过共享对象减少对象数目。
通过共享一个接口来避免使用多个具有相同信息的实例所带来的开销。
优点：
减少了要处理的对象数目。
如果对象能够持续，可以减少内存和存储设备。
以下情况中，应该使用Flyweight 模式：
应用程序使用大量的对象。
由于对象数目巨大，导致很高的存储开销。
不依赖于对象的身份。

 

三、行为性模式

行为性模式影响系统的状态、行为流。
简化、优化并且提高应用程序的可维护性。
1、Chain of Responsibility 模式
在系统中建立一个链，在首先接收到它的级别处被处理，或者定位到可以处理它的对象。
优点：
降低了耦合度。
增加面向对象制定责任的灵活性。
类的集合可以作为一个整体。
以下情况中，应该使用Chain of Responsibility 模式：

多个对象可以处理一个请求，而其处理器却是未知的。
在不指定确切的请求接受对象的情况下，向几个对象中的一个发送请求。
动态地指定能够处理请求的对象集。
2、Command 模式
在对象中封装了请求。
优点：
将调用操作的对象与知道如何完成该操作的对象相分离。
更容易添加新指令，因为不用修改已有类。
以下情况中，应该使用Command 模式：
要通过执行的动作来参数化对象。
在不同的时间指定、排序、执行请求。
必须支持Undo、日志记录或事务。
3、Interpreter 模式
解释定义其语法表示的语言，提供了语句解释器。
优点：
容易修改并扩展语法。
更容易实现语法。
以下情况中，应该使用Interpreter 模式：
语言的语法比较简单。
效率并不是最主要的问题。
4、Iterator 模式
为集合中的有序访问提供了一致的方法，而该集合是独立于基础集合。
优点：
支持集合的不同遍历。
简化了集合的接口。
以下情况中，应该使用Iterator 模式：
不开放集合对象内部表示的前提下，访问集合对象内容。
支持集合对象的多重遍历。
为遍历集合中的不同结构提供了统一的接口。

5、Mediator 模式
通过引入一个能够管理对象间消息分布的对象，简化了系统中对象间的通信。提高了对象间
的松耦合度，还可以独立地改变其间的交互。
优点：
去除对象间的影响。
简化了对象间协议。
集中化了控制。
由于不再需要直接互传消息，单个组件变得更加简单，而且容易处理。
由于不再需要包含逻辑来处理组件间的通信，组件变得更加通用。
以下情况中，应该使用Mediator 模式：
对象集合需要以一个定义规范但复杂的方式进行通信。
6、Memento 模式
保持对象状态的“快照”（snapshot），对象可以在不向外界公开其内容的情况下返回到它
的最初状态。
优点：
保持封装的完整性。
简化了返回到初始状态所需的操作。
以下情况中，应该使用Memento 模式：
必须保存对象状态的快照，恢复状态。
7、Observer 模式
定义了对象间一到多的依赖关系，当对象改变状态时，将自动通知并更新它所有的依赖
对象。
优点：
抽象了主题与Observer 之间的耦合关系。
支持广播方式通信。
以下情况中，应该使用Observer 模式：
对一个对象的修改涉及对其他对象的修改，而且不知道有多少对象需要进行相应修改。
对象应该能够在不同假设对象标识的前提下通知其它对象。
8、State 模式

对象在内部状态变化时，变更其行为，并且修改其类。
优点：
针对不同状态来划分行为，使状态转换显式进行。
9、Strategy 模式
定义了一组能够用来表示可能行为集合的类。这些行为可以在应用程序中使用，来修改应
用程序功能。
优点：
另一种子类化方法。
在类自身中定义了每一个行为，减少了条件语句。
更容易扩展模型。
以下情况中，应该使用Strategy 模式：
许多相关类只是在行为方面有所区别。
需要算法的不同变体。
算法使用客户端未知的数据。
10、Template Method 模式
不重写方法的前提下允许子类重载部分方法的方法。
将一些步骤由子类实现。
优点：代码重用的基础技术。
以下情况中，应该使用Template Method 模式：
一次实现算法的不变部分，子类实现算法的可变行为。
11、Visitor 模式
不改变操作元素的类的前提下定义一个新操作。
优点：
容易添加新操作。
集中相关排除不相关操作。
以下情况中，应该使用Visitor 模式：
包含许多具有不同接口的对象类，并且想要对这些依赖具体类的对象进行操作。
定义对象结构的类很少被修改，但想要在此结构上定义新的操作。

**********************************************************************************************************************************************************