设计模式笔记

说明：本文为GOF《Design Patterns》的阅读笔记

Abstract Factory

意图：

提供一个创建一系列相关或互相依赖对象的接口，而无需指定他们具体的类。

适用范围：

• 一个系统要独立于产品的创建、组合和表示时
• 一个系统要由多个产品系列中的一个来配置
• 需要强调一系列相关的产品对象的设计以便实现联合使用时
• 需要提供一个产品类库，只想显示他们的接口而不是实现时

例子：

比如要做一个应用程序GUI，它由ScrollBar，Window等组件按照一定的构造顺序和方式组成，那么我们可以做一层封装，提供一个Factory类，在Factory类内实现各GUI组件的构造，对外返回各组件构造的接口。

考虑到更复杂的一种情况，我们的GUI可能需要提供不同的风格，比如Gnome风格，或者Motif风格。这样，我们就可以提供两层的封装，第一层提供GnomeFactory和MotifFactory两个具体Factory类，而在这之上，提供一个抽象工厂，以隐藏具体的实现细节。

参与者：

• AbstractFactory 声明一个创建抽象产品对象的操作接口
• ConcreteFactory 实现创建具体产品对象的操作
• AbstractProduct 为一类产品对象声明一个接口
• ConcreteProduct 定义一个将被相应具体工厂创建的产品对象
• Clinet 仅使用由AbstractorFactory和AbstractProduct类声明的接口

Builder

意图：

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

适用性：

例子：

比如要做一个RTF Converter，它必须能够输出成不同格式的各种文档，例如ASCII File，Tex File，PDF File之类，它们由各自的类表示，而这些类由于差异较大，不可能有公共的父类。但是他们具体的创建者可以从一个抽想的创建者继承下来。换句话说，具体的ASCII File，PDF File之类的Concrete Builder必须对上层提供统一的接口，这个接口由Builder类定义。

这样，在RTF Converter中，对于RTF文档，根据用户的需求，可以调用Builder将RTF文档转换为所需要的格式。

参与者：

• Builder 为创建一个Product对象的各个部件指定抽象接口
• Concrete Builder 实现Builder的接口以构造和装配该产品的各个部件，定义并明确它所创建的表示，提供一个检索产品的接口
• Director 构造一个使用Builder对象
• Product 表示被构造的复杂对象，Concrete Builder创建该产品的内部表示并定义它的装配过程。

和Abstract Factory模式的区别：

• 两者相似，均用于创建复杂对象
• Builder模式着重于一步一步构造一个复杂对象
• Abstract Factory着重于多个系列的产品对象
• Builder在最后一步返回对象，而Abstract Factory立即返回产品

Factory Method

意图：

定义一个用于创建对象的接口，让子类决定实例化哪个类。Factory Method 使一个类的实例化延时到了子类。

适用性：

• 当一个类不知道它所必须创建的对象的类时
• 当一个类希望由它的子类来指定它所创建的对象时
• 当类将创建对象的职责委托给多个帮助子类中的某一个，并且希望将哪一个帮助子类是代理者这一信息局部化的时候。

参与者

• Product：定义工厂方法所创建的对象的接口
• Concrete Product：实现Product接口
• Creator：声明工厂方法，该方法返回一个Product类型的对象。Creator也可以定义一个工厂方法的缺省实现，它返回一个缺省的Concrete Product对象
• Concrete Creator：重定义工厂方法以返回一个Concrete Product 实例。

ProtoType原型

意图：

用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。

参与者：

• Proto Type：声明一个克隆自身的接口
• Concrete Proto Type：实现一个克隆自身的操作
• Client：让一个原型克隆自身从而创建一个新的对象

优点：

• 运行时刻可以增加或删除产品
• 改变值以指定新的对象
• 改变结构以指定新的对象
• 减少子类的构造
• 用类实现应用的动态配置

对C++的额外好处：

对于C++这样的静态语言，类不是对象，并且运行时刻得不到足够的类型信息，因此Proto Type特别有用。而对于Smalltalk或者Java这类语言而言，Proto Type就不是那么有用，因为这些语言提供了一个等价于原型的东西（即类对象）来创建每个类的实例。

Singleton

意图：

保证一个类仅有一个实例，并提供一个访问它的全局访问点

适用性：

• 当类只能有一个实例并且客户可以从一个众所周知的访问点访问它
• 当这个唯一的实例应该是通过子类化可扩展的，并且客户应该无需更改代码就能使用一个扩展的实例。

Adapter 适配器

意图：

将一个类的接口转换为客户所希望的另外一个接口

这种设计模式用的太多了，不多说了。

Bridge 桥接

意图：

将抽象部分和实现部分分离，使它们都可以独立地变化

例子：

对于一个Window类，如果对Window子类的所有操作都是通过WindowImp接口中的抽象操作实现的，这就可以将Window的抽象和系统平台相关的实现部分分离开来，因此，我们将Window和WindowImp的关系称为桥接。

参与者：

• Abstaction：1，定义一个抽象类的接口；2，维护一个指向Implementor对象的指针，Abstraction将client的请求转发给它的Implementor对象。
• Refine：扩充由Abstraction定义的接口。
• Implementor：定义实现类的接口，该接口不一定要和 Abstaction类的接口完全一致；事实上，这接口可以完全不同，一般来讲，Implementor接口仅提供基本操作，而Abstraction定义了基于这些基本操作的较高层次的操作。
• ConcreteImplementor 实现Implementor接口并定义它的具体实现。

Composite 组合

意图：

将对象组合成树形结构以表示“部分－整体”的层次结构，Composite使得用户对单个对象和组合对象的使用具有一致性。

不用说了

Decorator（装饰）

意图：

动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更加灵活。

例子：

比如要做一个Text Viewer，我们可以设计一个TextViewer类来实现基本的功能，而这个Viewer可能需要ScrollBar，可能需要Border边框。为了动态地给TextViewer添加这些装饰，我们可以设计一个抽象类Decorator以包含这些接口，子类ScrollBarDecorator和BorderDecorator继承自Decorator，并实现其接口。Decorator中维护了一个到TextViewer的指针，Decorator即是用户调用的接口。

适用性：

• 在不影响其他对象的情况下，以动态的，透明的方式给单个对象添加职责。
• 处理那些可以撤销的指责。
• 当不能采用生成子类的方法进行扩充时，一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长，另一种情况可能是因为类定义被隐藏，或类定义不能用于子类。

参与者：

• Component 定义一个对象接口，可以给这些对象动态地添加职责。
• ConcreteComponent 定义一个对象，可以给这个对象添加一些职责。
• Decorator 维持一个到Component对象的指针，并定义一个和Component接口一致的接口。
• ConcreteDecorator 向组件添加职责。

Facade （外观）

意图：

为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高级接口，这个接口使得这一子系统更加容易使用。

用的太多了，不用多说。

Flyweight （享元）

意图：

运用共享技术有效地使用大量细粒度的对象。

适用性：

Flyweight模式的有效性很大程度上取决于如何使用它以及在何处使用它。当以下情况都成立的时候使用Flyweight模式：

• 一个应用程序使用了大量的对象。
• 完全由于使用大量的对象，造成了很大的存储开销。
• 对象的大多数状态都可以改变为外部状态。
• 如果删除对象的外部状态，那么可以用相对较少的共享对象取代很多组对象
• 应用程序不依赖于对象标识，由于Flyweight对象可以被共享，对于概念上明显有区别的对象，标识测试将返回真值。

参与者：

• Flyweight：描述一个接口，通过这个接口flyweight可以接受并作用于外部状态。
• ConcreteFlyweight：实现Flyweight接口，并为内部状态增加存储空间。ConcreteFlyweight应该是可共享的，它所存储的状态必须是内部的，即它必须独立于ConcreteFlyweight对象的场景。
• UnsharedConcreteFlyweight 并非所有的Flyweight子类都要求共享，Flyweight接口使共享成为可能，但它并不强制共享，在Flyweight对象结构的某些层次，UnsharedConcreteFlyweight对象通常将ConcreteFlyweight对象作为子节点
• FlyweightFactory创建并管理Flyweight对象；确保合理地共享Flyweight，当用户请求一个Flyweight时，FlyweightFactory应该提供一个已创建的实例或者创建一个。 － Client：维持一个对flyweight的引用；计算或存储一个（或多个）flyweight的外部状态。

协作：

• Flyweight执行时所需要的状态必定是内部的或者是外部的，内部状态存储于ConcreteFlyweight对象中，而外部对象则由Client对象存储或计算，当用户调用flyweight对象的操作时，将该状态传递给它。
• 用户不应该直接对ConcreteFlyweight类进行实例化，而只能从FlyweightFactory对象得到ConcreteFlyweight对象，这可以保证对它们适当地进行共享。

Proxy （代理）

意图：

为其他对象提供一种代理以控制对这个对象的访问。

例子：

对一个对象进行访问控制的原因是为了只有在我们确实需要这个对象的时候才对它进行创建和初始化。比如对于一个可以在文档中嵌入图形对象的文档编辑器来说，有些图形对象的创建开销非常大，但是打开文档必须非常迅速。因此我们在打开文档时，应该避免一次性创建所有开销很大的对象。

例如这里的图像，我们可以设计一个图像的Proxy，包含了图像的尺寸，甚至缩略图等，打开文档的时候，只打开这些Proxy。仅仅在用户确实需要访问图像时，才创建这个图像的对象。

适用性：

以下是可以使用Proxy模式的常见情况：

• 远程代理：为一个对象在不同的地址空间提供局部代表
• 虚代理：根据需要创建开销很大的对象。例子中所述的就是这个情况。
• 保护代理：控制对原始对象的访问权限。
• 智能指针。

Proxy模式加上引用计数还可以对用户隐藏Copy-on-write的优化方式。

Chain of responsibility

意图：

使多个对象都有机会处理请求，从而避免请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它。

适用性：

在以下条件下使用Responsibility链：

• 有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定。
• 希望在不明确指定接受者的情况下，向多个对象中的一个提交一个请求。
• 可处理一个请求的对象集合应该被动态指定。

Command 命令

意图：

将一个请求封装成一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。

Command模式是回调机制的一个面向对象的替代品。

参与者：

• Command ：声明执行操作的接口
• ConcreteCommand：将一个接受者对象绑定于一个动作，调用接受者相应的操作，以实现Execute
• Client：创建一个具体的命令对象并设定它的接受者
• Invoker：要求该命令执行这个请求
• Receiver：知道如何实施与执行一个请求相关的操作。任何类都可以成为一个接受者。

Interpreter 解释器

意图：

给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子

Iterator 迭代器

意图：

提供一种方法顺序访问一个聚合对象中的各个元素，而不需要暴露对象的内部表示。

例子：

最经典的例子就是STL中的iterator

Mediator 中介者

意图：

用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立的改变他们之间的交互。

例子：

将一个系统划分为许多对象可以增强可复用性，但是对象间相互连接的激增又会降低其可复用性。我们可以将集体行为封装进一个单独的中介对象中避免这类问题。中介者充当一个中介使该组中的对象不再相互显式引用，这些对象仅知道中介者，从而减少了相互连接的数目。

Memento 备忘录

意图：

在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象外保存这个状态，这样以后就可以将该对象恢复到原先保存的状态。

注意：使用备忘录的代价可能很高。

Observer 观察者