02/06 软件设计模式

目录

一.创建型模式

抽象工厂 Abstract Factory

构建器 Builder

工厂方法 Factory Method

原型 Prototype

单例模式  Singleton

二.结构型模式

适配器模式  Adapter

桥接模式  Bridge

组合模式  Composite

装饰者模式  Decorator

外观模式  Facade

享元模式  Flyweight

代理模式  Proxy

三.行为型模式 Behavioral Patterns

责任链模式 Chain of Responsibility 

命令模式 Command 

解释器模式  Interpreter

迭代器模式 Iterator

中介者模式  Mediator

备忘录模式  Memento

观察者模式 Observer 

状态模式  State

策略模式  Strategy

访问者模式  Visitor

---

• 定义: 设计模式是针对软件设计中常见问题的可重用解决方案。

• 作用: 提高代码的可复用性、可维护性和可扩展性。

• 分类:

  • 创建型模式: 关注对象的创建过程，例如：工厂方法模式、抽象工厂模式、单例模式等。

  • 结构型模式: 关注类和对象的组合方式，例如：适配器模式、装饰器模式、代理模式等。

  • 行为型模式: 关注对象之间的通信和职责分配，例如：观察者模式、策略模式、模板方法模式等。

一.创建型模式

记忆方式：“单身的工人抽烟，想着建筑的原因。”

（５种）单例，工厂，抽象工厂，构建器，原型

---

抽象工厂 Abstract Factory

旨在提供一个接口，用于创建一系列相关或相互依赖的对象，而无需指定它们的具体类。它允许客户端代码在不需要了解具体实现的情况下，这个模式通常用于需要创建多个相关对象的场景，尤其是在产品族的情况下。

• （Abstract Factory）：抽象工厂 - 定义创建产品对象的接口。
• （Concrete Factory）：具体工厂 - 实现抽象工厂接口，负责创建具体的产品对象。
• （Abstract Product）：抽象产品 - 定义产品的接口。
• （Product）：具体产品 - 实现抽象产品接口的具体类。

使用场景：

- 当系统需要独立于其产品的创建、组合和表示时。

- 当系统需要使用多个系列的产品，而不需要依赖于具体的产品实现时。

- 当产品的具体类在运行时决定时。

---

构建器 Builder

旨在简化复杂对象的构建过程。它通过将对象的构建过程与其表示分离，使得同样的构建过程可以创建不同的表示。

• Builder（建造者）：定义创建一个产品所需的各个部件的抽象接口。
• ConcreteBuilder（具体建造者）：实现Builder接口，构建和装配各个部件，提供一个方法来返回构建好的产品。
• Director（指挥者）：负责管理Builder的构建过程，调用具体建造者的方法来构建产品。
• Product（产品）：最终构建的复杂对象。

使用场景：

- 当一个对象的构建过程复杂，且需要多个步骤时。

- 构造过程必须允许已构建对象有不同表示。

---

工厂方法 Factory Method

定义一个创建对象的接口，让子类决定实例化哪一个类。

• 产品接口（Product）：定义了工厂方法所创建的对象的接口。
• 具体产品（ConcreteProduct）：实现了Product产品接口的具体类。
• 工厂接口（Creator）：声明了一个工厂方法，返回一个Product产品对象。
• 具体工厂（ConcreteCreator）：实现了工厂接口，返回具体产品的实例。

---

原型 Prototype

它允许通过复制现有的实例来创建新对象，而不是通过直接实例化类。这种模式特别适合于需要创建大量相似对象的场景，能够提高性能并减少内存消耗。

• 原型接口（Prototype）：定义一个用于复制自身的接口。
• 具体原型（ConcretePrototype）：实现原型接口，提供具体的克隆方法。
• 客户端（Client）：使用原型实例来创建新的对象。

使用场景

- 当一个类的实例化成本较高时，可以考虑使用原型模式。

- 当需要创建大量相似对象时，原型模式可以有效减少内存消耗。

- 当对象的状态需要在运行时动态改变时，原型模式提供了灵活性。

---

单例模式  Singleton

确保一个类只有一个实例，并提供一个全局访问点。将类的构造函数私有化，并提供一个静态方法获取唯一实例。

它常用于需要控制资源访问的场景，比如数据库连接、线程池等。

使用场景

- 需要控制资源的访问，如数据库连接、线程池等。

- 需要全局访问的配置类。

- 需要在整个应用中共享的状态。

---

二.结构型模式

该类模式主要用于如何组合已有的类和对象以获得更大的结构，一般借鉴封装，代理，继承等概念讲一个或多个类或对象进行组合，封装，以提供同一的外部视图或新的功能。

记忆：“外桥享组装代”

适配器模式  Adapter

• 问题: 需要将一个类的接口转换成客户端期望的另一个接口。

• 解决方案: 创建一个适配器类，将目标接口转换成适配者接口。

• 记忆技巧: 适配器就像一个转接头，连接不兼容的接口。

• 1. **目标接口（Target）**：客户端所期待的接口。
• 2. **适配者（Adaptee）**：需要被适配的类，通常是已有的类。
• 3. **适配器（Adapter）**：实现目标接口，并持有一个适配者的实例，将目标接口的方法调用转发给适配者。

使用场景

- 当你希望使用一些现有的类，但其接口不符合你的需求时。

- 当你想要创建一个可以与多个不兼容接口的类协同工作的系统时。

---

桥接模式  Bridge

它通过将类的抽象部分与实现部分分离，使得二者可以独立变化。它是一种对象结构型模式，又称为柄体模式（Handle and Body ）或接口模式（Interface）这个模式主要用于解决类的层次结构过于复杂的问题

• 1. **抽象类（Abstraction）**：定义了抽象的接口，并维护一个指向Implementor实现的指针。
• 2. **扩展抽象类（Refined Abstraction）**：由Abstraction轴向类定义，扩展了抽象类的功能。
• 3. **实现类接口（Implementor）**：定义了实现部分的接口。这个接口不一定要和Abstraction的接口完全一致，可以完全不同，一把来说，Implementor接口仅提供基本操作，而Abstraction则定义了基于这些基本操作的较高层次的操作
• 4. **具体实现类（Concrete Implementor）**：实现了实现类接口，提供具体的实现。

适用场景

- 当你需要在多个维度上扩展系统时。

- 当你希望避免在类的层次结构中产生过多的子类时。

- 当你希望在运行时动态切换实现时。

---

组合模式  Composite

它允许将对象组合成树形结构以表示“部分-整体”的层次关系。组合模式使得客户端对单个对象和组合对象的使用具有一致性。

• 1. **组件（Component）**：定义了叶子和组合对象的共同接口。，所有的叶子节点和组合节点都需要实现这个接口。
• 2. **叶子节点（Leaf）**：实现了组件Component接口，表示树的叶子节点。它有自己的行为。
• 3. **组合节点（Composite）**：实现了组件接口，能够包含叶子和其他组合对象。它可以包含子节点（其他的叶子或组合节点），并实现了添加和删除子节点的方法。

适用场景

- 当需要表示对象的部分-整体层次结构时。

- 当希望客户端忽略组合对象和单个对象的差异时。

---

装饰者模式  Decorator

问题: 需要动态地给一个对象添加一些额外的职责。

解决方案: 创建一个装饰器类，包装原始对象，并在保持原始对象接口的前提下提供额外的功能。装饰器就像给蛋糕加奶油，可以不断添加新的装饰。

• 组件接口（Component）：定义一个对象接口，可以给这些对象动态地添加职责。
• 具体组件（ConcreteComponent）：实现了组件接口的具体对象，定义了被装饰的对象。
• 装饰器（Decorator）：持有一个组件对象的引用，并定义与组件接口一致的接口。
• 具体装饰器（ConcreteDecorator）：扩展了装饰器类，添加了额外的职责。

---

外观模式  Facade

它为复杂的子系统提供一个统一的接口，使得子系统更易于使用。通过外观模式，客户端可以通过一个简单的接口与复杂的系统进行交互，而不需要了解系统内部的复杂性。

外观类（Facade）：提供一个简单的接口，封装了复杂的子系统。

子系统类（Subsystem）：实现具体的功能，通常包含多个类，外观类通过这些类来完成具体的操作。

使用场景

- 当需要为复杂的子系统提供一个简单的接口时。

- 当需要解耦客户端与子系统之间的关系时。

- 当希望提高系统的可读性和可维护性时。

---

享元模式  Flyweight

旨在通过共享对象来减少内存使用和提高性能。它特别适用于大量相似对象的场景。享元模式的核心思想是将对象的状态分为两部分：内部状态和外部状态。

内部状态**：对象可以共享的状态，通常是不可变的。多个对象可以共享同一个内部状态。

外部状态**：对象特有的状态，通常是可变的。外部状态在使用对象时传递给对象。

• Flyweight：享元接口，定义了需要实现的方法。
• ConcreteFlyweight：具体享元类，实现了Flyweight接口，包含内部状态。
• FlyweightFactory：享元工厂，负责创建和管理享元对象，确保共享相同的对象。

使用场景:

当应用程序需要大量相似对象时。

当对象的创建和管理成本较高时。

当需要减少内存使用时。

---

代理模式  Proxy

• 问题: 需要控制对某个对象的访问，或者需要在访问对象时执行一些额外的操作。

• 解决方案: 创建一个代理类，代表原始对象，并在访问原始对象之前或之后执行一些操作。代理就像一个中介，控制对真实对象的访问

• 主题接口（Subject）：定义了代理和真实对象的共同接口。
• 真实主题（RealSubject）**：实现了主题接口，定义了代理所代表的真实对象。
• 代理 Proxy：持有对真实主题的引用，并实现了主题接口，控制对真实主题的访问。

代理模式通常用于以下几种情况：

1. **远程代理**：为一个对象在不同地址空间提供局部代表。

2. **虚拟代理**：根据需要创建开销较大的对象，延迟对象的创建。

3. **保护代理**：控制对原始对象的访问，提供不同的访问权限。

使用场景

-对象创建开销很大

- **网络请求**：在网络请求中，代理可以用于缓存响应，减少网络延迟。

- **权限控制**：在访问敏感数据时，代理可以检查用户权限。

- **资源管理**：在处理大对象时，代理可以延迟加载，优化性能。

---

三.行为型模式 Behavioral Patterns

该类模式主要用于对象之间的职责及其提供的服务的分配，它不仅描述对象或类的模式，还描述了他们之间的通信模式，特别是描述一组对等的对象怎样相互协作以完成其中任一对象都无法单独完成的任务。

记忆：10种

责命解，迭中备，观状策，访搞定。

• 责命解：责任链、命令、解释器。

• 迭中备：迭代器、中介者、备忘录。

• 观状策：观察者、状态、策略。

• 访搞定：访问者搞定一切！

责任链模式 Chain of Responsibility 

它允许将请求的发送者和接收者解耦，使多个对象都有机会处理请求。创建一个对象链，每个对象依次尝试处理请求，直到某个对象处理成功为止。

• 1. **Handler（处理者）**: 定义一个处理请求的接口，并实现链中的处理逻辑。
• 2. **ConcreteHandler（具体处理者）**: 实现Handler接口，处理请求或将请求传递给下一个处理者。
• 3. **Client（客户端）**: 创建具体处理者并设置链的顺序，发送请求。

工作原理

1. 客户端创建多个处理者，并将它们连接成一条链。

2. 客户端发送请求，链中的处理者依次检查是否能够处理该请求。

3. 如果某个处理者能够处理请求，则执行相应的处理逻辑；如果不能，则将请求传递给链中的下一个处理者。

应用场景：审批流程、异常处理、事件处理等。

---

命令模式 Command 

• 目的：将请求封装为对象，使得可以用不同的请求对客户进行参数化。

• 核心思想：将“操作”抽象为对象，支持撤销、重做、日志记录等功能。

• 1. **命令接口（Command）**：定义一个执行操作的接口。
• 2. **具体命令（ConcreteCommand）**：实现命令接口，定义与接收者之间的绑定关系，并调用接收者的相应操作。
• 3. **接收者（Receiver）**：知道如何实施与执行一个请求相关的操作。
• 4. **调用者（Invoker）**：负责调用命令对象来执行请求。
• 5. **客户端（Client）**：创建具体命令对象并设置接收者。
• 应用场景：GUI 按钮操作、任务队列、事务管理等。

---

解释器模式  Interpreter

• 目的：定义语言的文法规则，并解释执行语言中的句子。

• 核心思想：将语言中的每个符号映射为一个类，通过组合这些类来解析和执行语言。

• 应用场景：正则表达式解析、数学公式计算、编译器设计等。

• 1. 抽象表达式（AbstractExpression）：定义一个解释操作的接口，所有具体表达式都需要实现这个接口。
• 2. 终结符表达式（TerminalExpression）：实现了抽象表达式接口，表示文法中的基本元素。通常是一些简单的语法规则。
• 3. 非终结符表达式（NonTerminalExpression）：同样实现了抽象表达式接口，表示文法中的复杂结构，由多个终结符和非终结符组合而成。
• 4. 上下文（Context）：包含了在解释过程中需要的一些信息，通常是输入的字符串或其他数据。

工作原理

解释器模式的核心思想是将一个复杂的表达式分解为多个简单的表达式，然后通过递归的方式来解释这些表达式。

假设我们需要解析一个简单的数学表达式，比如加法和减法。我们可以定义以下结构：

- **抽象表达式**：`Expression` 接口，定义 `interpret(Context context)` 方法。

- **终结符表达式**：`NumberExpression` 类，表示数字。

- **非终结符表达式**：`AddExpression` 和 `SubtractExpression` 类，分别表示加法和减法。

具体步骤如下：

1. **定义文法**：首先需要定义要解析的语言的文法规则。

2. **构建表达式树**：根据文法规则构建一个表达式树，树的每个节点都是一个表达式。

3. **解释表达式**：通过遍历表达式树，调用每个节点的解释方法，最终得到结果。

使用场景（适用于特定的解析和执行需求）

- 需要系统要能应对“”自定义“”内容的解析。

- 需要解析和执行简单的语言或表达式。

- 需要对复杂的文法进行处理。

- 需要在运行时动态地解释和执行代码。

---

迭代器模式 Iterator

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

• 核心思想：将遍历逻辑从聚合对象中分离出来，封装到一个独立的迭代器对象中。

• 应用场景：集合类的遍历（如列表、树、图等）。

• 1. **迭代器（Iterator）**：定义了访问和遍历元素的接口。
• 2. **具体迭代器（Concrete Iterator）**：实现了迭代器接口，负责遍历具体集合的元素。
• 3. **聚合（Aggregate）**：定义了创建迭代器的接口。
• 4. **具体聚合（Concrete Aggregate）**：实现了聚合接口，返回一个具体的迭代器。

---

中介者模式  Mediator

• 目的：用一个中介对象来封装一系列对象之间的交互，降低对象之间的耦合度。

• 核心思想：将对象之间的直接通信改为通过中介者间接通信。

• 应用场景：聊天室、事件调度系统、GUI 组件交互等。

• 1. **中介者接口（Mediator）**：定义了与各个同事对象交互的方法。
• 2. **具体中介者（ConcreteMediator）**：实现中介者接口，维护对各个同事对象的引用，并协调它们之间的交互。
• 3. **同事类（Colleague）**：各个参与者，它们通过中介者进行交互，而不是直接相互交互。

---

备忘录模式  Memento

• 目的：在不破坏封装性的前提下，捕获并外部化一个对象的内部状态，以便以后恢复。

• 核心思想：将对象的状态保存到备忘录对象中，并在需要时恢复。

• 应用场景：撤销操作、游戏存档、事务回滚等。

这使得它在需要状态管理的应用程序中非常有用。

• 1. **Originator（发起人）**：需要保存其内部状态的对象。它可以创建一个备忘录来记录当前状态，并可以使用备忘录恢复状态。
• 2. **Memento（备忘录）**：用于存储发起人的内部状态。备忘录通常是一个不可变的对象，外部对象无法直接访问其内部状态。
• 3. **Caretaker（看护者）**：负责管理备忘录的对象。看护者可以保存和恢复备忘录，但不能修改备忘录的内容。

使用场景

- 文本编辑器的撤销/重做功能。

- 游戏中的状态保存与加载。

- 任何需要保存和恢复对象状态的场景。

---

观察者模式 Observer 

• 问题: 当一个对象的状态发生改变时，需要通知其他对象，并且这些对象之间是松耦合的。

• 解决方案: 定义一种一对多的依赖关系，当一个对象改变状态时，所有依赖它的对象都会收到通知并自动更新。

• 记忆技巧: 观察者模式就像订阅报纸，当有新报纸时，订阅者会自动收到。

• 1. **主题（Subject）**：被观察的对象，维护观察者的列表，并提供注册、注销观察者的方法。
• 2. **观察者（Observer）**：依赖于主题的对象，当主题状态变化时，观察者会收到通知并进行相应的更新。
• 3. **具体主题（Concrete Subject）**：实现了主题接口的具体类，包含状态变化的逻辑。
• 4. **具体观察者（Concrete Observer）**：实现了观察者接口的具体类，定义了在接收到通知时的行为。

---

状态模式  State

• 目的：允许对象在其内部状态改变时改变其行为，使得对象看起来像是修改了它的类。

• 核心思想：将状态抽象为独立的类，对象的行为随状态的变化而变化。

• 应用场景：工作流系统、游戏角色状态、订单状态管理等。

• 1. **Context（上下文）**：持有一个状态对象的引用，并且可以在运行时改变它的状态。
• 2. **State（状态接口）**：定义一个接口，用于封装与特定状态相关的行为。
• 3. **ConcreteState（具体状态）**：实现状态接口的具体状态类，每个具体状态类都实现了与该状态相关的行为。

工作原理

- 上下文对象持有一个状态对象的引用。

- 当上下文的状态改变时，它会将状态对象替换为另一个状态对象。

- 每个状态对象实现了状态接口中的方法，定义了在该状态下的具体行为。

---

策略模式  Strategy

它定义了一系列算法，将每个算法封装起来，并使它们可以互换。策略模式让算法独立于使用它的客户端而变化。

• 1. **策略接口（Strategy）**：定义一个公共接口，所有具体策略都需要实现这个接口。
• 2. **具体策略（ConcreteStrategy）**：实现策略接口的具体算法。
• 3. **上下文（Context）**：持有一个策略的引用，并可以在运行时选择具体的策略。

使用场景

- 当你有多个算法可以选择，并且希望在运行时选择其中一个。

- 当你希望将算法的实现与使用算法的代码分离。

- 当你需要避免使用大量的条件语句（如 `if-else` 或 `switch`）。

---

访问者模式  Visitor

它允许你在不改变对象结构的前提下，定义新的操作。这个模式的核心思想是将算法与对象结构分离，使得你可以在不修改对象的情况下，添加新的操作。适用于需要对一组对象执行多种操作的场景。

• 1. **Visitor（访问者）**: 定义了对每个元素的访问操作。
• 2. **Element（元素）**: 接受访问者的访问，通常是一个接口或抽象类。
• 3. **ConcreteElement（具体元素）**: 实现了 Element 接口的具体类。
• 4. **ObjectStructure（对象结构）**: 维护一组元素，并提供一个方法来允许访问者访问这些元素。

工作原理

- 访问者模式通过在元素类中定义一个 `accept` 方法，接受一个访问者对象。

- 访问者对象实现了对每个具体元素的操作。

- 当访问者访问元素时，元素会调用访问者的相应方法，从而实现对元素的操作。

---