小菜鸟

桥接模式（Bridge Pattern）：拆分继承树，实现抽象与实现的独立演化

桥接模式是结构型设计模式的一种，核心思想是将抽象部分与实现部分分离，使两者可以独立变化。它通过 “组合” 替代 “继承”，解决了因多维度变化导致的 “类爆炸” 问题，让抽象和实现能够沿着各自的维度灵活扩展。

桥接模式的核心结构

桥接模式通过四个核心角色实现抽象与实现的分离，形成清晰的 “桥接” 关系：

实现部分（Implementor）

• 定义实现部分的接口，声明具体实现的基本操作（与抽象部分的业务逻辑无关，仅提供底层能力）。
• 示例：DrawingAPI（绘图接口，定义绘制图形的底层方法）。

具体实现（ConcreteImplementor）

• 实现 Implementor 接口，提供具体的底层实现（如不同的技术、平台、工具等）。
• 示例：OpenGLAPI、DirectXAPI（分别基于 OpenGL 和 DirectX 的绘图实现）。

抽象部分（Abstraction）

• 定义抽象部分的接口，包含对实现部分的引用（通过组合关联 Implementor），并声明高层业务逻辑。
• 示例：Shape（图形抽象类，持有DrawingAPI的引用，定义图形的绘制逻辑）。

扩展抽象（RefinedAbstraction）

• 扩展抽象部分的接口，添加更具体的业务逻辑，但不直接涉及实现细节（依赖实现部分的接口完成操作）。
• 示例：Circle、Rectangle（具体图形，继承Shape并扩展其功能）。

代码实现示例

以 “跨平台图形绘制” 为例：抽象部分为 “图形”（如圆形、矩形），实现部分为 “绘图 API”（如 OpenGL、DirectX），桥接模式使图形与绘图技术独立变化。

1. 实现部分（Implementor 与 ConcreteImplementor）

解释器模式（Interpreter Pattern）：自定义语言的解析与执行

解释器模式是行为型设计模式的一种，核心思想是为特定语言定义语法规则，并构建一个解释器来解析和执行该语言的句子。它就像一个 “迷你虚拟机”，能理解自定义的语法规则并按规则执行相应操作，本质是 “分离语法实现，解释执行句子”。

解释器模式的核心结构

解释器模式通过四个核心角色实现语法解析与执行，层次分明且分工明确：

抽象表达式（AbstractExpression）

• 定义所有解释器的公共接口，声明一个interpret(Context context)方法，用于解释句子（处理上下文并返回结果）。
• 示例：Expression（表达式接口，声明interpret()方法）。

终结符表达式（TerminalExpression）

• 实现抽象表达式接口，处理语法中的终结符（语法中不可再分的基本元素）。
• 示例：NumberExpression（解析数字）、VariableExpression（解析变量）。

非终结符表达式（NonterminalExpression）

• 实现抽象表达式接口，处理语法中的非终结符（由多个终结符或非终结符组合而成的复杂规则）。
• 示例：AddExpression（解析加法运算）、MultiplyExpression（解析乘法运算）。

上下文（Context）

• 存储解释器需要的全局信息（如变量映射、中间结果），为解释过程提供数据支持。
• 示例：MathContext（存储变量的值，如x=5、y=3）。

代码实现示例

以 “简单数学表达式解析器” 为例，展示解释器模式的实现：支持整数、变量及加法运算（如x + 3、5 + y）。

组合模式（Composite Pattern）：构建 “部分 - 整体” 的树形结构

组合模式是结构型设计模式的一种，核心思想是将对象组合成树形结构以表示 “部分 - 整体” 的层次关系，使客户端对单个对象（叶子节点）和组合对象（容器节点）的使用具有一致性。这种模式就像文件系统中的 “文件夹 - 文件” 结构，无论是单个文件还是文件夹（包含多个文件），都可以用统一的方式操作。

组合模式的核心结构

组合模式通过三个核心角色构建树形结构，实现对 “部分” 和 “整体” 的统一处理：

抽象组件（Component）

• 定义所有组件（叶子节点和组合节点）的公共接口，声明了添加、移除子组件、获取子组件及核心业务方法。
• 示例：FileSystemNode（文件系统节点接口，定义getName()、getSize()等方法）。

叶子节点（Leaf）

• 表示树形结构中的最小单元（不可再包含子组件），实现抽象组件的接口，但不支持子组件操作（如添加、移除）。
• 示例：File（文件，不可包含子节点）。

组合节点（Composite）

• 表示树形结构中的容器（可包含子组件，子组件可以是叶子节点或其他组合节点），实现抽象组件的接口，负责管理子组件（添加、移除、遍历）。
• 示例：Folder（文件夹，可包含文件或子文件夹）。

代码实现示例

以 “文件系统” 为例，展示组合模式的实现：文件夹（Composite）可包含文件（Leaf）或子文件夹，客户端可统一获取大小、打印结构等。

1. 抽象组件（Component）

门面模式（Facade Pattern）：简化复杂系统的访问接口

门面模式（又称外观模式）是结构型设计模式的一种，核心思想是为多个复杂的子系统提供一个统一的高层接口，通过这个接口简化客户端与子系统的交互，屏蔽内部细节。这种模式就像 “前台服务员”，客户端无需直接与后台多个部门打交道，只需通过前台即可完成所有操作。

门面模式的核心结构

门面模式的结构简单清晰，主要包含两个角色：

门面角色（Facade）

• 定义一个统一的接口，负责协调多个子系统的交互。
• 客户端通过调用门面角色的方法间接访问子系统，无需了解子系统的具体实现。

子系统角色（Subsystem）

• 由多个相互关联或独立的类组成，实现具体的业务逻辑。
• 子系统不知道门面角色的存在，仅关注自身功能的实现。

代码实现示例

以 “家庭影院系统” 为例，子系统包括投影仪、音响、播放器等，门面角色 “影院控制器” 提供一键播放功能，简化操作：

子系统角色（各类设备）

备忘录模式（Memento Pattern）：对象状态的快照与恢复

备忘录模式是行为型设计模式的一种，核心思想是在不破坏对象封装性的前提下，捕获对象的内部状态并保存，以便后续将对象恢复到该状态。这种模式就像 “游戏存档”—— 玩家可在关键时刻保存进度，后续可随时加载存档回到之前的状态，核心功能是 “状态的保存与恢复”。

备忘录模式的核心结构

备忘录模式通过三个核心角色实现状态的安全存储与恢复，分工明确且保障封装性：

原发器（Originator）

• 需要被保存状态的对象，负责创建备忘录（记录当前状态）和从备忘录恢复状态。
• 示例：GameRole（游戏角色，需保存生命值、魔法值等状态）。

备忘录（Memento）

• 存储原发器状态的对象，通常由原发器创建，包含原发器的部分或全部内部状态。
• 备忘录的访问权限严格控制：仅允许原发器读写其状态，其他对象无法修改（保障封装性）。
• 示例：GameRoleMemento（存储游戏角色的生命值、魔法值）。

管理者（Caretaker）

• 负责管理备忘录的对象，仅存储备忘录但不查看或修改其内容，相当于 “存档管理器”。
• 示例：GameSaveManager（保存多个游戏存档，提供存档和读档接口）。

代码实现示例

以 “游戏角色状态存档” 为例，展示备忘录模式的实现：游戏角色可保存当前状态（生命值、魔法值），并在需要时恢复。