本文主要是介绍《设计模式：可复用面向对象软件的基础》读书笔记（3），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
这篇博客记录了书中《第3章：创建型模式》里的要点。
介绍
创建型设计模式抽象了实例化过程。
在这些模式中有两个不断出现的主旋律：
- 他们都将关于该系统使用哪些具体的类的信息封装起来。
- 他们隐藏了这些类的实例是如何被创建和放在一起的。
整个系统关于这些对象所知道的是由抽象类所定义的接口。因此，创建型模式在什么被创建、谁创建它、它是怎样被创建的，以及何时被创建等方面给予你很大的灵活性。
下面将这一章的5个模式一起研究，来突出他们的相似点和差异点。
举一个通用的例子：为一个游戏创建一个迷宫。例如，迷宫中的类有：
MapSite是迷宫所有组件的公共抽象类
Room继承MapSite，代表一个房间。
Wall继承MapSite，代表一面墙。
Maze代表一个迷宫。
MazeGame来创建迷宫。
创建型模式目的是使得这个设计更灵活，即更易于修改。（但是代码量上未必会更少）。
Abstract Factory（抽象工厂）
意图
提供一个接口以创建一系列相关或相互依赖的对象，而无须指定它们具体的类。
特点
- 分离了具体的类
- 易于改变产品的系列
- 易于保持产品系列的一致性
- 难以支持新种类的产品
代码示例
MazeFactory类负责创建迷宫的构件。CreateMaze函数将一个MazeFactory作为参数。
EnchantedMazeFactory类会创建施了魔法的迷宫构件。
BombedMazeFactory类会创建有炸弹功能的房间。
相关模式
一个具体的工厂通常是一个 Singleton
Builder（生成器）
意图
将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以构建不同的表示。
特点
- 可以改变一个产品的内部表示。
- 将构造代码和表示代码分开
- 可以对构造过程进行更精细的控制
代码示例
MazeBuilder类负责创建迷宫的构件。CreateMaze函数将一个MazeBuilder作为参数。MazeBuilder提供了一个接口，其函数定义了一些空实现，其子类做实际的工作。
StandardMazeBuilder是一个创建简单迷宫的实现。
CountingMazeBuilder很特殊，他根本不创建迷宫，仅仅对已经被创建的构件进行计数。
相关模式
Builder模式 和 Abstract Factory模式 都可以创建复杂的对象，但是区别在于：
Builder强调一步步构造一个复杂对象，而Abstract Factory着重于创建多个系列的产品。Builder在最后一步返回产品，而Abstract Factory立即返回。
Factory Method（工厂函数）
意图
定义一个用于创建对象的接口，让子类决定实例化哪一个类。
想要解决的问题
一个应用类想要创建一个产品对象并操作时，它不知道想要创建哪一个子类产品，这时候可以定义一个工厂函数，返回一个基类产品对象。应用类的子类来决定创建哪一种子类产品。这时候应用类就可以直接调用他自己的工厂函数来创建对象随后操作了。
特点
- 不再将与特定应用有关的类绑定到代码中，代码仅处理基类接口。
- 缺点是想创建新产品时，必须创建新的子类。（可以用模板解决这个问题）
- 可以提供一个合理的默认实现，子类就算不继承也不会有问题
- 连接平行的类层次
代码示例
MazeGame是基类，其中有MakeRoom和MakeWall等创建迷宫组件的函数。
BombedMazeGame继承MazeGame，它实现的MakeRoom创建的是一个爆炸房间。
EnchantedMazeGame继承MazeGame，它实现的MakeRoom创建的是一个有魔法符文的房间。
相关模式
Abstract Factory 经常使用这种模式来创建产品对象。
Prototype（原型）
意图
用原型实例指定创建对象的种类，并且通过拷贝这些原型来创建新的对象。
想要解决的问题
不同种类的对象如果每个都创建一个子类，会造成太多子类。为此，可以建立一个“原型”，创建对象时拷贝它并做一些操作。
特点
- 运行时增加和删除产品
- 改变值以指定新对象
- 改变结构以指定新对象
- 减少子类的构造
- 用类动态配置应用
- 缺点是，每一个prototype的子类必须实现克隆操作
代码示例
MazePrototypeFactory继承MazeFactory，它在构造函数中将一些原型作为参数。
Singleton（单例）
意图
保证一个类仅有一个实例，并提供一个访问它的全局访问点。
特点
- 对唯一实例的受控访问
- 缩小名字空间
- 允许对操作和表示的精化
- 允许可变数目的实例
- 比类操作更灵活
相关模式
很多模式都可以是 Singleton
其他名言
灵活性和接口的扩展性是需要权衡的
通常，设计以使用 Factory Method 开始，当设计者发现需要更大的灵活性时，设计便会向其他创建型模式演化。
我的感想
设计模式之间并不总是对等、互斥的。他们之间可以是相互配合的，更像是一种“思想”。英文Pattern——图案，这个词挺好：图案之间可以有对等的（例如正方形图案和圆形图案），也可以有相互配合的（例如正方形图案和花边图案）。
这篇关于《设计模式：可复用面向对象软件的基础》读书笔记（3）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
