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. **解释表达式**：通过遍历表达式树，调用每个节点的解释方法，最终得到结果。

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

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

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

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

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