设计模式简介
"设计模式"源于GOF（四人帮）合著出版的《设计模式：可复用的面向对象软件元素》，该书第一次完整科普了软件开发中设计模式的概念，他们提出的设计模式主要是基于以下的面向对象设计原则：
- 对接口编程而不是对实现编程
- 优先使用对象组合而不是继承
根据该书所提到的，总共有 23 种设计模式，这些模式可以分为以下三大类：
1）创建型模式
这些模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用 new 运算符直接实例化对象，这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活
包括：工厂模式、抽象工厂模式、单例模式、建造者模式、原型模式
2）结构型模式
这些模式关注对象之间的组合和关系，旨在解决如何构建灵活且可复用的类和对象结构
包括：适配器模式、桥接模式、过滤器模式、组合模式、装饰器模式、外观模式、享元模式、代理模式
3）行为型模式
这些模式关注对象之间的通信和交互，旨在解决对象之间的责任分配和算法的封装
包括：责任链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、空对象模式、策略模式、模板模式、访问者模式
下图描述设计模式之间的关系：
设计模式的六大原则
1）开闭原则
开闭原则是指：对扩展开发，对修改关闭。在程序需要进行扩展的时候，不能去修改原有的代码，想要达到这样的效果，我们需要使用接口和抽象类
2）里氏代换原则
里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。该原则其实是对开闭原则的补充，实现开闭原则的关键步骤是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范
3）依赖倒转原则
这个原则是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体
4）接口隔离原则
接口隔离原则是指：使用多个隔离的接口，比使用单个接口要好，还有个意思是：降低类之间的耦合度
5）迪米特原则（又称：最少知道原则）
最少知道原则是指：一个实体尽量少地与其他实体发生相互作用，使得系统功能模块相互独立
6）合成复用原则
合成复用原则是指：尽量使用合成/聚合的方式，而不是使用继承
工厂模式
工厂模式提供了一种创建对象的方式，而无需指定要创建的具体类。通过使用工厂模式，可以将对象的创建逻辑封装到一个工厂类里，而不是在客户端代码中直接实例化对象
工厂模式主要有以下几种类型：
1）简单工厂模式
简单工厂模式不是一个正式的设计模式，但它是工厂模式的基础，它使用一个单独的工厂类来创建不同的对象，根据传入的参数决定创建哪种类型的对象
2）工厂方法模式
工厂方法模式定义了一个创建对象的接口，但由子类决定实例化哪个类，工厂方法将对象的创建延迟到子类
3）抽象工厂模式
抽象工厂模式提供一个创建一系列相关或互相依赖对象的接口，而无需指定它们具体的类
当我们需要在不同条件下创建不同实例时可以使用工厂模式，它的使用场景主要有以下几个：
1）日志记录：日志可能记录到本地硬盘、远程服务器等，用户可以选择记录日志的位置
2）数据库访问：当用户不知道最终系统使用哪种数据库，或者数据库可能变化时
PS：工厂模式适用于生成复杂对象的场景，如果对象较为简单，通过 new 即可完成创建，而不必使用工厂模式，使用工厂模式会引入一个工厂类，增加系统复杂度
它的优缺点：
1）优点
- 调用者只需要知道对象的名称即可创建对象
- 扩展性高：如果需要增加新产品，只需扩展一个工厂类即可
- 屏蔽了产品的具体实现，调用者只关心产品的接口
2）缺点
每次增加一个产品时，都需要增加一个具体类和对应的工厂，使系统中类的数量成倍增加，增加了系统的复杂度和具体类的依赖
工厂模式包含以下几个主要角色：
1）抽象产品
定义了产品的共同接口或抽象类，它可以是具体产品类的父类或接口，规定了产品对象的共同方法
2）具体产品
实现了抽象产品接口，定义了具体产品的特定行为和属性
3）抽象工厂
声明了创建产品的抽象方法，可以是接口或抽象类，它可以有多个方法用于创建不同类型的产品
4）具体工厂
实现了抽象工厂接口，负责实际创建具体产品的对象
我们通过以下一个简单的实例来展示工厂模式的实现，假设我们有不同种类的button需要创建，每个按钮有不同的实现
1）定义抽象产品和具体产品
Button类是一个抽象类（接口），它有两个方法：render()用于渲染按钮，onClick()用于按钮点击后的行为
WindowsButton和 MacButton分别实现了Button接口，提供具体的渲染和点击行为
// 抽象产品：button
class Button {render() {throw new Error('方法 "render()" 被实现')}onClick() {throw new Error('方法 "onClick()" 被实现')}
}// 具体产品：Windows 按钮
class WindowsButton extends Button {render() {console.log('渲染 Windows 按钮')}onClick() {console.log('点击了 Windows 按钮')}
}// 具体产品：Mac 按钮
class MacButton extends Button {render() {console.log('渲染 Mac 按钮')}onClick() {console.log('点击了 Mac 按钮')}
}
2）定义抽象工厂和具体工厂
ButtonFactory是工厂接口，定义了createButton()方法，用来创建具体的按钮
WindowsButtonFactory和MacButtonFactory分别实现了createButton()方法，创建不同操作系统的按钮
// 工厂接口
class ButtonFactory {createButton() {throw new Error('方法 "createButton()" 被实现')}
}// 具体工厂：Windows 按钮工厂
class WindowsButtonFactory extends ButtonFactory {createButton() {console.log('创建 Windows 按钮')return new WindowsButton()}
}// 具体工厂：Mac 按钮工厂
class MacButtonFactory extends ButtonFactory {createButton() {console.log('创建 Mac 按钮')return new MacButton()}
}
3）使用工厂创建对象
renderButton() 是客户端方法，通过传入工厂对象来创建并使用按钮
// 客户端代码：根据需要选择不同的工厂来创建不同的按钮
function renderButton(factory) {const button = factory.createButton()button.render() button.onClick()
}// 模拟渲染不同操作系统的按钮
console.log('Windows 按钮：')
renderButton(new WindowsButtonFactory())console.log('Mac 按钮：')
renderButton(new MacButtonFactory())
执行上述代码，控制台打印出：
抽象工厂模式
抽象工厂模式是工厂模式的扩展，它提供一个接口，用于创建一系列相关或相互依赖的对象，而无需指定具体的类，换句话说，抽象工厂模式为一组产品提供了一个接口，这组产品可能有多个不同的具体实现，而每一个具体工厂类都负责创建这些产品的不同实现
它的使用场景主要有以下几个：
1）系统需要多个产品族的产品在一起工作，但不需要指定具体类时
2）系统需要独立于产品的创建、组合和表示时
它的优缺点：
1）优点
- 确保同一产品族的对象一起工作
- 客户端不需要知道每个对象的具体类，简化了代码
2）缺点
增加一个新的产品族需要修改抽象工厂和所有具体工厂的代码
假设我们需要在多个操作系统上创建不同风格的按钮和文本框，将使用抽象工厂模式来创建这些 UI 元素，以便在不同操作系统上使用相应的样式
1）定义抽象产品接口
定义Button和TextBox作为抽象产品，它们是各个操作系统上的 UI 元素
// 抽象产品：Button
class Button {render() {throw new Error('方法 "render()" 被实现')}onClick() {throw new Error('方法 "onClick()" 被实现')}
}
// 抽象产品：TextBox
class TextBox {render() {throw new Error('方法 "render()" 被实现')}onFocus() {throw new Error('方法 "onFocus()" 被实现')}
}
2）定义具体产品
定义具体产品类：WindowsButton、MacButton、WindowsTextBox和MacTextBox，它们实现了上述的抽象产品接口
// 具体产品：Windows 按钮
class WindowsButton extends Button {render() {console.log('渲染 Windows 按钮')}onClick() {console.log('点击了 Windows 按钮')}
}
// 具体产品：Mac 按钮
class MacButton extends Button {render() {console.log('渲染 Mac 按钮')}onClick() {console.log('点击了 Mac 按钮')}
}
// 具体产品：Windows 文本框
class WindowsTextBox extends TextBox {render() {console.log('渲染 Windows 文本框')}onFocus() {console.log('Windows 文本框获得焦点')}
}
// 具体产品：Mac 文本框
class MacTextBox extends TextBox {render() {console.log('渲染 Mac 文本框')}onFocus() {console.log('Mac 文本框获得焦点')}
}
3）定义抽象工厂接口
UIFactory是抽象工厂接口，定义了两个方法：createButton和createTextBox，用来创建按钮和文本框
// 抽象工厂接口：UIFactory
class UIFactory {createButton() {throw new Error('方法 "createButton()" 必须被实现')}createTextBox() {throw new Error('方法 "createTextBox()" 必须被实现')}
}
4）定义具体工厂
具体工厂WindowsFactory和MacFactory负责实例化具体的 UI 元素（按钮和文本框）
// 具体工厂：Windows 工厂
class WindowsFactory extends UIFactory {createButton() {console.log('创建 Windows 按钮')return new WindowsButton()}createTextBox() {console.log('创建 Windows 文本框')return new WindowsTextBox()}
}
// 具体工厂：Mac 工厂
class MacFactory extends UIFactory {createButton() {console.log('创建 Mac 按钮')return new MacButton()}createTextBox() {console.log('创建 Mac 文本框')return new MacTextBox()}
}
5）客户端使用工厂
根据需求选择不同的工厂来创建产品（按钮和文本框），而不关心具体的产品实现
// 客户端代码：根据工厂创建 UI 元素
function renderUI(factory) {const button = factory.createButton() button.render() button.onClick() const textBox = factory.createTextBox() textBox.render() textBox.onFocus()
}console.log('渲染 Windows 风格的 UI:')
renderUI(new WindowsFactory())console.log('渲染 Mac 风格的 UI:')
renderUI(new MacFactory())
执行上述代码，控制台打印出：
单例模式
单例模式确保一个类只有一个实例，并提供了一个全局访问点来访问该实例，需要注意的是：
1）单例类只能有一个实例
2）单例类必须自己创建自己的唯一实例
3）单例类必须给其他对象提供这一实例
当需要控制实例数量，节省系统资源时可以使用单例模式，它的使用场景主要有以下几个：
1）生成唯一序列号
2）创建消耗资源过多的对象，比如：I/O、数据库连接等
3）如果某个计算的结果是全局唯一且不希望重复计算，可以使用单例模式缓存该结果，确保第一次计算后复用该结果
它的缺点：
1）没有接口，不能继承
2）与单一职责原则冲突，一个类应该只关心内部逻辑，而不关心实例化方式
单例模式可以使用以下不同的方法来实现：
1）懒汉式
在首次调用时创建实例，适合资源消耗较大的情况
2）饿汉式
在类加载时创建实例，适合在程序启动时就需要用到实例的情况
懒汉式
懒汉式的单例模式是在需要实例的时候才创建实例，实例是延迟加载的，只有在第一次访问时才会创建
第一次创建instance1时，Singleton的构造函数会初始化实例并存储在Singleton.instance中；第二次创建instance2时，由于Singleton.instance已经存在，构造函数直接返回已有的实例
class Singleton {constructor() {// 如果实例已经存在，直接返回该实例if (Singleton.instance) {return Singleton.instance}// 否则就初始化实例this.value = Math.random()Singleton.instance = this}getValue() {return this.value}
}// 测试
const instance1 = new Singleton()
console.log(instance1.getValue())const instance2 = new Singleton()
console.log(instance2.getValue())console.log(instance1 === instance2) // 输出 true，说明是同一个实例
在 JavaScript 中，单线程模型通常不会遇到并发问题，但是在多线程环境中，如果多个线程同时调用new Singleton()，可能会创建多个实例，违背了单例模式的原则
为了避免多个线程并发访问时创建多个实例，我们可以通过加锁来确保同一时刻只有一个线程能创建实例，使用 synchronized 来进行加锁
在 JavaScript 中实现"上锁"的概念时，通常使用一个标志变量（如lock）来模拟锁的功能
通过Singleton.lock来确保只有一个线程能执行实例创建的代码，其他线程在此期间会被阻塞，直到锁被释放；在try...finally结构中，确保即使发生异常，也能释放锁
class Singleton {constructor() {// 如果实例已经存在，直接返回该实例if (Singleton.instance) {return Singleton.instance}// 模拟线程安全的加锁机制if (!Singleton.lock) {Singleton.lock = true // 上锁try {// 如果没有实例，则创建一个this.value = Math.random()Singleton.instance = this} finally {Singleton.lock = false // 解锁}}}getValue() {return this.value}
}// 测试
const instance1 = new Singleton()
console.log(instance1.getValue())const instance2 = new Singleton()
console.log(instance2.getValue())console.log(instance1 === instance2) // 输出 true，说明是同一个实例
饿汉式
饿汉式的单例模式与懒汉式不同，它在类加载时就创建好实例，饿汉式实现不需要考虑线程安全问题，因为实例在类加载时就创建好了，只有一个线程能访问类加载阶段
在下面的实现中，Singleton.instance是类加载时就创建好的静态属性，因此无论多少次访问，都返回相同的实例
class Singleton {static instance = new Singleton()constructor() {if (Singleton.instance) {return Singleton.instance}this.value = Math.random() }getValue() {return this.value}
}// 测试
const instance1 = Singleton.instance
console.log(instance1.getValue())const instance2 = Singleton.instance
console.log(instance2.getValue())console.log(instance1 === instance2) // 输出 true，说明是同一个实例
建造者模式
建造者模式将复杂对象的构建与表示分离，使得同样的构建过程可以创建不同的对象
它的使用场景主要有以下：
1）当一个对象的构建过程很复杂，可能涉及多个步骤，且这些步骤可以独立进行
2）需要支持产品的多种表现形式（不同配置、不同组合）
PS：与工厂模式的区别是：建造者模式更加关注于零件装配的顺序
它的优缺点：
1）优点
- 分离构建过程和表示，可以构建不同的表示
- 代码复用性高，可以在不同的构建过程中重复使用相同的建造者
2）缺点
- 如果产品属性较少，该模式会导致代码冗余
- 增加了系统的类和对象数量
建造者模式包含以下几个主要角色：
1）产品
要构建的复杂对象，产品类通常包含多个部分或属性
2）抽象建造者
定义了构建产品的抽象接口，包括构建产品的各个部分的方法
3）具体建造者
实现抽象建造者接口，具体确定如何构建产品的各个部分，并负责返回最终构建的产品
4）指导者
负责调用建造者的方法来构建产品，指导者并不了解具体的构建过程，只关心产品的构建顺序和方式
假设我们需要构建一辆汽车，汽车有多个部件，不同配置的汽车有不同的部件组合，下面通过建造者模式来组织这个构建过程
1）定义产品类
构建一个汽车产品类，它有多个部件：引擎、轮胎、车窗
class Car {constructor() {this.engine = nullthis.tires = nullthis.windows = null}show() {console.log(`汽车配置：引擎: ${this.engine}, 轮胎: ${this.tires}, 车窗: ${this.windows}`)}
}
2）定义抽象建造者
建造者类定义了构建汽车的各个步骤，但不包含具体的实现
//抽象建造者：CarBuilder
class CarBuilder {buildEngine() {throw new Error('子类实现 buildEngine 方法')}buildTires() {throw new Error('子类实现 buildTires 方法')}buildWindows() {throw new Error('子类实现 buildWindows 方法')}getCar() {throw new Error('子类实现 getCar 方法')}
}
3）定义具体建造者
具体建造者类继承CarBuilder，并实现了具体的构建过程，这里定义了两种不同配置的汽车：普通汽车和豪华汽车
//具体建造者：普通汽车 NormalCarBuilder
class NormalCarBuilder extends CarBuilder {constructor() {super()this.car = new Car()}buildEngine() {this.car.engine = '普通引擎'}buildTires() {this.car.tires = '普通轮胎'}buildWindows() {this.car.windows = '普通车窗'}getCar() {return this.car}
}
//具体建造者：豪华汽车 LuxuryCarBuilder
class LuxuryCarBuilder extends CarBuilder {constructor() {super()this.car = new Car()}buildEngine() {this.car.engine = '豪华引擎'}buildTires() {this.car.tires = '豪华轮胎'}buildWindows() {this.car.windows = '豪华车窗'}getCar() {return this.car}
}
4）定义指导者
指导者负责按照一定的顺序，调用建造者类的方法，来创建汽车
//指导者：Director
class Director {constructor(builder) {this.builder = builder}construct() {this.builder.buildEngine()this.builder.buildTires()this.builder.buildWindows()}
}
5）客户端
客户端通过指导者来控制建造过程，最终得到一个构建好的汽车对象
// 客户端代码
const normalCarBuilder = new NormalCarBuilder()
const normalDirector = new Director(normalCarBuilder)normalDirector.construct()
const normalCar = normalCarBuilder.getCar()
normalCar.show() // 输出: 汽车配置：引擎: 普通引擎, 轮胎: 普通轮胎, 车窗: 普通车窗const luxuryCarBuilder = new LuxuryCarBuilder()
const luxuryDirector = new Director(luxuryCarBuilder)luxuryDirector.construct()
const luxuryCar = luxuryCarBuilder.getCar()
luxuryCar.show() // 输出: 汽车配置：引擎: 豪华引擎, 轮胎: 豪华轮胎, 车窗: 豪华车窗
原型模式
原型模式通过复制现有的对象来创建新对象，而不是通过直接构造新的对象，避免了重复初始化复杂对象的开销
它的使用场景主要有以下几个：
1）类初始化需要消耗大量资源，如数据、硬件资源
2）通过 new 创建对象需要复杂的数据准备或访问权限时
3）一个对象需要多个修改者
PS：与直接实例化类创建新对象不同，原型模式通过拷贝现有对象生成新对象
它的优缺点：
1）优点
- 性能提高
- 避免构造函数的约束
2）缺点
配置克隆方法需要全面考虑类的功能，对已有类可能较难实现，特别是处理不支持串行化的间接对象或含有循环结构的引用时
原型模式包含以下几个主要角色：
1）原型接口
定义一个用于克隆自身的接口，通常包含一个 clone() 方法
2）具体原型类
实现圆形接口的具体类，负责实际的克隆操作，通常使用浅拷贝或深拷贝来复制自身
- 浅拷贝：复制对象时，原始对象的属性值会被复制到新对象中，但如果属性是引用类型，则会复制引用而不是实际的对象
- 深拷贝：不仅复制对象本身的属性，还会递归地复制对象中引用类型的属性，从而确保新对象完全独立于原始对象
3）客户端
使用原型实例来创建新的对象，客户端调用原型对象的 clone() 方法来创建新的对象，而不是直接使用构造函数
假设我们需要复制一个游戏角色，这个角色有多个属性，如名字、血量、装备等，通过克隆原始角色来创建一个新的角色
1）创建一个GameCharacter类
// 原型类：游戏角色
class GameCharacter {constructor(name, health, weapons) {this.name = name this.health = health this.weapons = weapons }// 显示角色信息display() {console.log(`角色：${this.name}, 血量：${this.health}, 武器：${this.weapons.join(', ')}`)}// 克隆方法 - 浅拷贝clone() {return new GameCharacter(this.name, this.health, [...this.weapons])}
}
2）创建一个简单的角色对象
// 创建一个角色
const originalCharacter = new GameCharacter("战士", 100, ["剑", "盾"])
originalCharacter.display()
3）克隆角色
// 克隆角色
const clonedCharacter = originalCharacter.clone()
clonedCharacter.display()
4）修改克隆后的对象
修改克隆后的角色，看看它是否独立于原始对象：
// 修改克隆后的角色
clonedCharacter.name = "弓箭手"
clonedCharacter.health = 80
clonedCharacter.weapons.push("弓")// 显示修改后的角色信息
clonedCharacter.display()// 显示原始角色信息
originalCharacter.display()
从以下输出中可以看出，原始角色和克隆后的角色是独立的，修改克隆角色的属性不会影响原始角色
当前的 clone 方法是浅拷贝，它会直接复制对象的引用类型属性，如 weapons 数组，如果修改了克隆角色的weapons，会影响到原始角色
为了避免这个问题，我们可以在 clone 方法中使用深拷贝，保证即使 weapons 是引用类型，也会完全复制
// 深拷贝：确保复制所有引用类型的内容
clone() {return new GameCharacter(this.name, this.health, JSON.parse(JSON.stringify(this.weapons)))
}
 入门指南)
)
