23种设计模式的分类和功能——创建型模式篇｜七日打卡

本篇示例都是用 Typesciprt 写的。

背景

“设计模式”这个术语最初并不是出现在软件设计中，而是被用于建筑领域的设计中。

1977 年，美国著名建筑大师、加利福尼亚大学伯克利分校环境结构中心主任克里斯托夫·亚历山大（Christopher Alexander）在他的著作《建筑模式语言：城镇、建筑、构造（A Pattern Language: Towns Building Construction）》中描述了一些常见的建筑设计问题，并提出了 253 种关于对城镇、邻里、住宅、花园和房间等进行设计的基本模式。

1987 年，肯特·贝克（Kent Beck）和沃德·坎宁安（Ward Cunningham）首先将克里斯托夫·亚历山大的模式思想应用在 Smalltalk 中的图形用户接口的生成中，但没有引起软件界的关注。

直到 1990 年，软件工程界才开始研讨设计模式的话题，后来召开了多次关于设计模式的研讨会。

软件设计模式的概念与意义

软件设计模式（Software Design Pattern），又称设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。它描述了在软件设计过程中的一些不断重复发生的问题，以及该问题的解决方案。也就是说，它是解决特定问题的一系列套路，是前辈们的代码设计经验的总结，具有一定的普遍性，可以反复使用。其目的是为了提高代码的可重用性、代码的可读性和代码的可靠性。

GoF 的 23 种设计模式的分类和功能

1. 单例（Singleton）模式：某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例，其拓展是有限多例模式。
2. 原型（Prototype）模式：将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例
3. 工厂方法（Factory Method）模式：定义一个用于创建产品的接口，由子类决定生产什么产品。
4. 抽象工厂（AbstractFactory）模式：提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品。
5. 建造者（Builder）模式：将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象。
6. 代理（Proxy）模式：为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。
7. 适配器（Adapter）模式：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。
8. 桥接（Bridge）模式：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。
9. 装饰（Decorator）模式：动态的给对象增加一些职责，即增加其额外的功能。
10. 外观（Facade）模式：为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。
11. 享元（Flyweight）模式：运用共享技术来有效地支持大量细粒度对象的复用。
12. 组合（Composite）模式：将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性。
13. 模板方法（TemplateMethod）模式：定义一个操作中的算法骨架，而将算法的一些步骤延迟到子类中，使得子类可以不改变该算法结构的情况下重定义该算法的某些特定步骤。
14. 策略（Strategy）模式：定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响使用算法的客户。
15. 命令（Command）模式：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。
16. 职责链（Chain of Responsibility）模式：把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通过这种方式去除对象之间的耦合。
17. 状态（State）模式：允许一个对象在其内部状态发生改变时改变其行为能力。
18. 观察者（Observer）模式：多个对象间存在一对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象，从而影响其他对象的行为。
19. 中介者（Mediator）模式：定义一个中介对象来简化原有对象之间的交互关系，降低系统中对象间的耦合度，使原有对象之间不必相互了解。
20. 迭代器（Iterator）模式：提供一种方法来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。
21. 访问者（Visitor）模式：在不改变集合元素的前提下，为一个集合中的每个元素提供多种访问方式，即每个元素有多个访问者对象访问。
22. 备忘录（Memento）模式：在不破坏封装性的前提下，获取并保存一个对象的内部状态，以便以后恢复它。
23. 解释器（Interpreter）模式：提供如何定义语言的文法，以及对语言句子的解释方法，即解释器。

创建型模式

1. 单例模式

优点：

• 单例模式可以保证内存里只有一个实例，减少了内存的开销。
• 可以避免对资源的多种占用。
• 单例模式设置全局访问点，可以优化和共享资源的访问。

缺点

• 单例模式一般没有接口，扩展困难。如果要扩展，则除了修改原来的代码，没有第二种途径，违背开闭原则。
• 在并发测试中，单例模式不利于代码调试。在调试过程中，如果单例中的代码没有执行完，也不能模拟生成一个新的对象。
• 单例模式的功能代码通常写在一个类中，如果功能设计不合理，则很容易违背单一职责原则。

应用场景

• 需要频繁创建的一些类，使用单例可以降低系统的内存压力，减少 GC。
• 某类只要求生成一个对象的时候，如一个班中的班长、每个人的身份证号等。
• 某些类创建实例时占用资源较多，或实例化耗时较长，且经常使用。
• 某类需要频繁实例化，而创建的对象又频繁被销毁的时候，如多线程的线程池、网络连接池等。
• 频繁访问数据库或文件的对象。
• 对于一些控制硬件级别的操作，或者从系统上来讲应当是单一控制逻辑的操作，如果有多个实例，则系统会完全乱套。
• 当对象需要被共享的场合。由于单例模式只允许创建一个对象，共享该对象可以节省内存，并加快对象访问速度。如 Web 中的配置对象、数据库的连接池等。

单例模式的结构与实现

结构

单例模式的主要角色

• 单例类：包含一个实例且能自行创建这个实例的类。
• 访问类：使用单例的类。

实现

Singleton 模式通常有两种实现形式。

第1种，饿汉式

class UserApi {
  private static _instance = new UserApi();

  private constructor() {} // private 保证了无法在外部使用 new XXX() 来创建对象

  public static getInstance() {
    return UserApi._instance;
  }
}

UserApi.getInstance();

第2种，懒汉式

class UserApi {
  private static _instance: UserApi;

  private constructor() {}

  public static getInstance() {
    if (!UserApi._instance) {
      UserApi._instance = new UserApi();
    }
    return UserApi._instance;
  }
}

UserApi.getInstance();

懒汉式和饿汉式的区别：

1. 线程安全

   饿汉式是线程安全的，懒汉式则不是。由于类的实例化也是需要时间的，当多个线程同时需要初始化一个类，第一个线程走到这行代码时UserApi._instance = new UserApi();开始初始化实例，但还未赋值，第二个线程走到if (!UserApi._instance)的判断时，发现还没有实例，也会实例化一个，这样系统中就会出现2个实例，可能就会影响到系统的正常运行。

2. 加载性能

   由于饿汉式是系统初始化就会自动实例化，所以会导致系统初始化相对慢一些，实际用到的时候获取实例会很快。而懒汉式则是在实际使用到的时候才初始化，不会拖累系统的初始化，但实际用的时候速度会慢一点。

当然懒汉式并非不能做到做到线程安全，在一些语言中可以使用 同步锁 的方式来保证类不会被多次实例化。

2. 原型模式

优点

• 可以使用深克隆/深拷贝的方式保存对象的状态，使用原型模式将对象复制一份，并将其状态保存起来，简化了创建对象的过程，以便在需要的时候使用（例如恢复到历史某一状态），可辅助实现撤销操作。

缺点

• 需要为每个类都配置一个clone方法
• Clone 方法位于类的内部，当对已有的类进行改造的时候，需要修改代码，违背了开闭原则
• 当实现深克隆时，需要编写较为复杂的代码，而且当对象之间存在多重嵌套引用时，为了实现克隆，每一层对象对应的类都必须支持深克隆，实现起来会比较麻烦。因此，深克隆、浅克隆需要运用得当。

原型模式的结构与实现

结构

• 抽象原型类
• 具体原型类
• 访问类

实现

原型模式的克隆分为浅克隆和深克隆。

• 浅克隆：创建一个新对象，新对象的属性和原来对象完全相同，对于非基本类型属性，仍指向原有属性所指向的对象的内存地址。
• 深克隆：创建一个新对象，属性中引用的其他对象也会被克隆，不再指向原有对象地址。

在 Javascript 中，我们可以使用 object.create(proto) 来克隆对象，proto 会成为新对象的原型，注意不要去修改非基本类型的属性，会影响到原型对象。

在 Javascript 中，我们可以使用 es6的扩展运算符 ... 和 Object.assign 来进行浅拷贝，借用 lodash 的 deepClone 实现深拷贝。

原型模式的应用场景

原型模式的浅克隆在前端应用的很多，如react component 的state就是浅克隆，redux的reducer更新也是用的浅克隆。

原型模式通常适用于一下场景

• 对象之间相同或相似，即只是个别的几个属性不同的时候。
• 创建对象成本较大，例如初始化时间长，占用CPU太多，或者占用网络资源太多等，需要优化资源。
• 创建一个对象需要繁琐的数据准备或访问权限等，需要提高性能或者提高安全性。
• 系统中大量使用该类对象，且各个调用者都需要给它的属性重新赋值。

原型模式的扩展

原型模式可扩展为带原型管理器的原型模式，它在原型模式的基础上增加了一个原型管理器 PrototypeManager 类。该类用 hash 保存多个复制的原型，Client 类可以通过管理器的 get(key: String) 方法从中获取复制的原型。

3. 工厂模式

定义

定义一个创建产品对象的工厂接口，将产品对象的实际创建工作推迟到具体子工厂类当中。这满足创建型模式中所要求的“创建与使用相分离”的特点。

按实际业务场景划分，工厂模式有 3 种不同的实现方式，分别是简单工厂模式、工厂方法模式和抽象工厂模式。

我们把被创建的对象称为“产品”，把创建产品的对象称为“工厂”。如果要创建的产品不多，只要一个工厂类就可以完成，这种模式叫“简单工厂模式”。

在简单工厂模式中创建实例的方法通常为静态（static）方法，因此简单工厂模式（Simple Factory Pattern）又叫静态工厂方法模式（Static Factory Method Pattern）。

4. 建造者模式

定义

指将一个复杂对象的构造与它的表示分离，使同样的构建过程可以创建不同的表示，这样的设计模式被称为建造者模式。它是将一个复杂的对象分解为多个简单的对象，然后一步一步构建而成。它将变与不变相分离，即产品的组成部分是不变的，但每一部分是可以灵活选择的。

优点

• 封装性好，构建和表示分离。
• 扩展性好，各个具体的建造者相互独立，有利于系统的解耦。
• 客户端不必知道产品内部组成的细节，建造者可以对创建过程逐步细化，而不对其它模块产生任何影响，便于控制细节风险。

缺点

• 产品的组成部分必须相同，这限制了其使用范围。
• 如果产品的内部变化复杂，如果产品内部发生变化，则建造者也要同步修改，后期维护成本较大。

建造者（Builder）模式和工厂模式的关注点不同：建造者模式注重零部件的组装过程，而工厂方法模式更注重零部件的创建过程，但两者可以结合使用。

建造者模式的结构与实现

结构

• 产品角色（Product）
• 抽象建造者（Builder）
• 具体建造者（Concrete Builder）
• 指挥者（Director）

实现

产品角色：包含多个组成部件的复杂对象。

class Product {
  private partA: string;
  private partB: string;
  private partC: string;

  public setPartA(partA: string) {
    this.partA = partA;
  }

  public setPartB(partB: string) {
    this.partB = partB;
  }

  public setPartC(partC: string) {
    this.partC = partC;
  }

  public show(): void {
    // 显示产品特性
  }
}

抽象建造者： 包含创建产品各个子部件的抽象方法。

abstract class Builder {
  // 创建产品对象
  protected product = new Product();

  public abstract buildPartA(): void;

  public abstract buildPartB(): void;

  public abstract buildPartC(): void;
	
  // 返回产品对象
  public getResult() {
    return this.product;
  }
}

具体建造者： 实现了抽象建造者接口

class ConcreteBuilder extends Builder {
  public buildPartA() {
    this.product.setPartA("建造 PartA");
  }

  public buildPartB() {
    this.product.setPartB("建造 PartB");
  }

  public buildPartC() {
    this.product.setPartC("建造 PartC");
  }
}

指挥者： 调用建造中的方法完成复杂对象的创建

class Director {
  private builder: Builder;

  constructor(builder: Builder) {
    this.builder = builder;
  }

  public construct(): Product {
    this.builder.buildPartA();
    this.builder.buildPartB();
    this.builder.buildPartC();
    return this.builder.getResult();
  }
}

最后调用

const builder = new ConcreteBuilder(); // 建造者
const director = new Director(builder); // 指挥者
const product = director.construct(); // 指挥者命令建造
product.show();

建造者模式的应用场景

建造者模式唯一区别于工厂模式的是针对复杂对象的创建。也就是说，如果创建简单对象，通常都是使用工厂模式进行创建，而如果创建复杂对象，就可以考虑使用建造者模式。

当需要创建的产品具备复杂创建过程时，可以抽取出共性创建过程，然后交由具体实现类自定义创建流程，使得同样的创建行为可以生产出不同的产品，分离了创建与表示，使创建产品的灵活性大大增加。

建造者模式主要适用于以下应用场景：

• 相同的方法，不同的执行顺序，产生不同的结果。
• 多个部件或零件，都可以装配到一个对象中，但是产生的结果又不相同。
• 产品类非常复杂，或者产品类中不同的调用顺序产生不同的作用。
• 初始化一个对象特别复杂，参数多，而且很多参数都具有默认值。