Design Pattern
创建型设计模式（Creational Patterns）
创建型模式用于创建对象，同时隐藏创建逻辑，而不是直接使用 new 操作符实例化对象。
这些模式可以简化对象的创建过程，提高代码的灵活性和可维护性。常见的创建型模式包括：
单例模式（Singleton Pattern）
核心思想
- 私有化构造函数：防止外部通过new创建实例
- 静态私有成员变量：保存类的唯一实例
- 静态公有方法：提供全局访问点，通常命名为getInstance()
应用场景
- 需要频繁创建和销毁的对象
- 创建对象耗时过多或耗费资源过多
- 工具类对象
- 频繁访问数据库或文件的对象
- 系统只需要一个实例的对象，如配置管理器、连接池等
GIL 对线程安全的影响
- GIL 确保 Python 字节码级别的原子操作是线程安全的
- 但单例模式的 if not instance 检查后跟实例创建不是原子操作
- 因此即使有 GIL，仍然需要显式加锁来保证线程安全
实现
装饰器版本
- 优点：非侵入式，可复用性强
- 特点：使用闭包保存实例字典和锁
- 关键点：双重检查锁定减少锁竞争
- 适用场景：需要给现有类快速添加单例特性
类实现版本
- 优点：逻辑直观，易于理解
- 特点：类变量存储实例，类方法控制创建
- 关键点：
__new__方法重写 - 适用场景：明确需要单例的新建类
元类版本
- 优点：最彻底的实现方式
- 特点：通过元类控制实例化过程
- 关键点：重写
__call__方法 - 适用场景：需要框架级单例控制
lru_cache实现
工厂方法模式（Factory Method Pattern）
工厂方法模式(Factory Method Pattern)是一种创建型设计模式，它定义了一个创建对象的接口，但让子类决定实例化哪一个类。
工厂方法使一个类的实例化延迟到其子类。
- Product（抽象产品）：定义产品的接口
- ConcreteProduct（具体产品）：实现抽象产品接口的具体类
- Creator（抽象工厂）：声明工厂方法，返回一个Product类型的对象
- ConcreteCreator（具体工厂）：重写工厂方法以返回一个ConcreteProduct实例
实现步骤
- 定义抽象产品接口
- 使用ABC和@abstractmethod创建抽象基类
- 定义产品必须实现的接口方法
- 实现具体产品类
- 每个具体产品必须实现抽象产品定义的接口
- 可以添加产品特有的方法和属性
- 定义抽象工厂接口
- 工厂方法通常返回抽象产品类型
- 工厂方法可以有参数，用于决定创建哪种具体产品
- 实现具体工厂类
- 每个具体工厂负责创建一种具体产品
- 工厂方法返回具体产品实例
- 客户端使用
- 客户端只依赖抽象工厂和抽象产品
- 通过传入不同的工厂来创建不同的产品
- 客户端代码不需要知道具体产品类
客户端 → 调用 → 具体工厂 → 创建 → 具体产品
↑
实现工厂接口
↑
继承抽象工厂sequenceDiagram
participant Client as 客户端
participant AliPayFactory as 支付宝工厂
participant WechatPayFactory as 微信支付工厂
participant BankPayFactory as 银行卡工厂
participant Alipay as 支付宝支付
participant WechatPay as 微信支付
participant BankPay as 银行卡支付
Note over Client: 支付宝支付流程
Client->>AliPayFactory: create_payment()
AliPayFactory->>Alipay: 创建实例
Alipay-->>Client: 返回支付对象
Client->>Alipay: pay(100)
Alipay-->>Client: "使用支付宝支付了100元"
Note over Client: 微信支付流程
Client->>WechatPayFactory: create_payment()
WechatPayFactory->>WechatPay: 创建实例
WechatPay-->>Client: 返回支付对象
Client->>WechatPay: pay(200)
WechatPay-->>Client: "使用微信支付了200元"
Note over Client: 银行卡支付流程
Client->>BankPayFactory: create_payment()
BankPayFactory->>BankPay: 创建实例
BankPay-->>Client: 返回支付对象
Client->>BankPay: pay(300)
BankPay-->>Client: "使用银行卡支付了300元"模式优缺点
- 优点：
- 避免了创建者和具体产品之间的紧密耦合
- 单一职责原则：将产品创建代码放在单一位置，便于维护
- 开闭原则：无需修改现有客户端代码就可以引入新产品
- 缺点：
- 需要引入许多新的子类，代码可能会变得更加复杂
- 对于简单的对象创建场景，可能会显得过于复杂
适用场景
- 当一个类不知道它所需要的对象的类时
- 当一个类希望由它的子类来指定它所创建的对象时
- 当类将创建对象的职责委托给多个帮助子类中的某一个，并且你希望将哪一个帮助子类是代理者这一信息局部化的时候
抽象工厂模式（Abstract Factory Pattern）
抽象工厂模式是一种创建型设计模式，它提供了一种方式来创建相关或依赖对象的家族，而无需指定它们的具体类。
与工厂方法模式（创建单个对象）不同，抽象工厂模式关注的是创建多个相关对象。
核心角色
- AbstractFactory（抽象工厂）：声明创建一系列产品对象的接口
- ConcreteFactory（具体工厂）：实现抽象工厂的接口，创建具体的产品对象
- AbstractProduct（抽象产品）：为每种产品声明接口
- ConcreteProduct（具体产品）：实现抽象产品接口的具体类
- Client（客户端）：使用抽象工厂和抽象产品接口
实现步骤
- 定义抽象产品接口（如 Button、Textbox）。
- 为每个平台实现具体产品类（如 WinButton、MacButton）。
- 定义抽象工厂接口，声明创建产品的方法。
- 为每个平台实现具体工厂类（如 WindowsFactory、MacOSFactory）。
- 客户端通过抽象工厂接口创建产品，运行时选择具体工厂。
调用链路
sequenceDiagram
participant Client as 客户端
participant WindowsFactory as Windows工厂
participant MacFactory as Mac工厂
participant WindowsButton as Windows按钮
participant WindowsCheckbox as Windows复选框
participant MacButton as Mac按钮
participant MacCheckbox as Mac复选框
Note over Client: Windows风格调用流程
Client->>WindowsFactory: create_button()
WindowsFactory->>WindowsButton: 创建实例
WindowsButton-->>Client: 返回按钮对象
Client->>WindowsFactory: create_checkbox()
WindowsFactory->>WindowsCheckbox: 创建实例
WindowsCheckbox-->>Client: 返回复选框对象
Client->>WindowsButton: render()
WindowsButton-->>Client: "渲染Windows风格按钮"
Client->>WindowsCheckbox: render()
WindowsCheckbox-->>Client: "渲染Windows风格复选框"
Note over Client: Mac风格调用流程
Client->>MacFactory: create_button()
MacFactory->>MacButton: 创建实例
MacButton-->>Client: 返回按钮对象
Client->>MacFactory: create_checkbox()
MacFactory->>MacCheckbox: 创建实例
MacCheckbox-->>Client: 返回复选框对象
Client->>MacButton: render()
MacButton-->>Client: "渲染Mac风格按钮"
Client->>MacCheckbox: render()
MacCheckbox-->>Client: "渲染Mac风格复选框"优缺点
- 优点：
- 确保产品兼容性（同一工厂创建的产品能一起工作）
- 客户端与具体类解耦
- 易于交换产品系列
- 符合单一职责和开闭原则
- 缺点：
- 增加新种类产品困难（需要修改所有工厂类）
- 代码复杂度增加
- 过度设计风险（对简单系统可能不必要）
适用场景
- 系统需要独立于其产品的创建、组合和表示时
- 系统需要配置多个产品族中的一个时
- 需要强调一系列相关产品的设计约束时
- 需要提供产品类库，只暴露接口不暴露实现时
与工厂方法模式对比
| 比较维度 | 工厂方法模式 | 抽象工厂模式 |
|---|---|---|
| 创建对象 | 单个产品 | 产品家族（多个相关对象） |
| 扩展方向 | 添加新产品种类容易 | 添加新产品族容易 |
| 复杂度 | 相对简单 | 相对复杂 |
| 典型应用 | 单一对象的创建 | 需要确保产品兼容性的系统 |
建造者模式（Builder Pattern）
建造者模式是一种创建型设计模式，它允许你分步骤创建复杂对象。
该模式能够使用相同的创建代码生成不同类型和表现的对象。
主要角色
- Product 被构造的复杂对象（如：Computer、Car）
- Builder 抽象建造者接口，声明构建产品各部件的方法
- ConcreteBuilder 具体建造者，实现 Builder 接口，负责实际构造产品的各个部分
- Director 指挥者，定义构建顺序，控制 Builder 的执行流程（可选）
- Client 使用 Builder 和 Director 来创建对象
实现关键点
- 分步骤构建：将复杂对象的构建过程拆分为多个可复用的步骤。
- 解耦：将构建逻辑与产品表示分离，避免构造函数臃肿。
- 可变性：通过更换 Builder 实现，创建不同表示的同一产品。
- 链式调用（Fluent Interface）（Python 中常用）：支持
.build_part1().build_part2()的流畅写法。
实现步骤 （以构建一台电脑为例）
- 定义产品类 Computer，包含多个可选部件。
- 定义抽象建造者接口 ComputerBuilder，声明构建各部件的方法。
- 实现具体建造者 GamingComputerBuilder、OfficeComputerBuilder。
- 可选：定义指挥者 Director，封装构建流程。
- 客户端通过建造者或 Director 构建对象。
sequenceDiagram
participant Client as 客户端
participant Director as 指挥者
participant GamingBuilder as 游戏建造者
participant OfficeBuilder as 办公建造者
participant GamingComputer as 游戏电脑
participant OfficeComputer as 办公电脑
Note over Client: 构建游戏电脑流程
Client->>GamingBuilder: 创建建造者实例
Client->>Director: 新建指挥者(GamingBuilder)
Client->>Director: construct_gaming_computer()
Director->>GamingBuilder: add_cpu("Intel i9")
Director->>GamingBuilder: add_memory("32GB DDR5")
Director->>GamingBuilder: add_disk("2TB SSD")
Director->>GamingBuilder: add_gpu("RTX 4090")
Director->>GamingBuilder: get_computer()
GamingBuilder-->>Director: 返回GamingComputer
Director-->>Client: 返回完整游戏电脑
Client->>GamingComputer: 使用电脑
Note over Client: 构建办公电脑流程
Client->>OfficeBuilder: 创建建造者实例
Client->>Director: 新建指挥者(OfficeBuilder)
Client->>Director: construct_office_computer()
Director->>OfficeBuilder: add_cpu("Intel i5")
Director->>OfficeBuilder: add_memory("16GB DDR4")
Director->>OfficeBuilder: add_disk("512GB SSD")
Director->>OfficeBuilder: add_gpu("集成显卡")
Director->>OfficeBuilder: get_computer()
OfficeBuilder-->>Director: 返回OfficeComputer
Director-->>Client: 返回完整办公电脑
Client->>OfficeComputer: 使用电脑
优缺点
优点：
- 封装性好，构建与表示分离
- 扩展性好，新增具体建造者无需修改现有代码
- 可以精细控制构建过程
- 可以复用相同的构建代码创建不同产品
缺点：
- 产品组成部分必须相似，建造者模式才有意义
- 果产品内部变化复杂，会导致需要定义很多具体建造者类
- 增加了系统复杂度
适用场景
- 需要生成的产品对象有复杂的内部结构
- 需要生成的产品对象的属性相互依赖，需要指定其生成顺序
- 对象的创建过程独立于组成该对象的部件
- 隔离复杂对象的创建和使用
原型模式（Prototype Pattern）
原型模式是一种创建型设计模式，它通过复制现有对象来创建新对象，而不是通过新建类实例的方式。
这种模式特别适用于创建成本较高的对象，或者需要动态配置的对象。
核心角色
- Prototype（抽象原型）：声明克隆方法的接口
- ConcretePrototype（具体原型）：实现克隆方法的具体类
- Client（客户端）：通过请求原型克隆新对象
关键特点
- 对象复制：通过复制现有对象创建新对象
- 性能优化：避免昂贵的初始化操作
- 动态配置：可以保存对象状态作为原型
- 简化创建：客户端无需知道具体类名
实现步骤
- 定义抽象原型接口：
- 声明克隆方法
- 定义对象的基本接口
- 实现具体原型类：
- 实现克隆方法（深拷贝或浅拷贝）
- 包含必要的初始化逻辑
- 创建原型管理器（可选）：
- 存储常用原型
- 提供克隆接口
- 客户端使用：
- 从原型管理器获取原型
- 克隆并修改新对象
sequenceDiagram
participant Client as 客户端
participant Registry as 原型管理器
participant ReportProto as 报表原型
participant LetterProto as 信件原型
participant ReportCopy as 报表副本
participant LetterCopy as 信件副本
Note over Client: 初始化阶段
Client->>ReportProto: 创建原型("年度报告",...)
Client->>LetterProto: 创建原型("尊敬的客户",...)
Client->>Registry: register("report", ReportProto)
Client->>Registry: register("letter", LetterProto)
Note over Client: 克隆报表文档
Client->>Registry: clone_document("report")
Registry->>ReportProto: clone()
ReportProto->>ReportCopy: 深拷贝创建副本
ReportCopy-->>Registry: 返回副本
Registry-->>Client: 返回ReportCopy
Client->>ReportCopy: display()
Note over Client: 克隆并修改信件
Client->>Registry: clone_document("letter", body="新内容")
Registry->>LetterProto: clone()
LetterProto->>LetterCopy: 浅拷贝创建副本
LetterCopy->>LetterCopy: 修改body属性
LetterCopy-->>Registry: 返回副本
Registry-->>Client: 返回LetterCopy
Client->>LetterCopy: display()优缺点
- 优点：
- 性能优化：避免昂贵的初始化操作
- 动态配置：运行时添加或删除原型
- 简化子类：减少类的数量
- 保存对象状态：可以保存特定状态作为原型
- 缺点：
- 克隆复杂对象可能困难
- 深拷贝可能带来性能问题
- 需要正确实现克隆方法
适用场景
- 需要创建的对象独立于其类型和创建方式
- 需要动态加载类
- 对象创建成本较高（如需要复杂计算或IO操作）
- 需要保存对象状态作为配置
结构型设计模式（Structural Patterns）
结构型模式用于处理类或对象的组合，通过组合对象或类来实现新的功能。
这些模式主要关注如何将对象组合成更大的结构。常见的结构型模式包括：
适配器模式（Adapter Pattern）
适配器模式（Adapter Pattern）是一种结构型设计模式，它允许接口不兼容的类能够一起工作。
适配器模式就像现实世界中的电源适配器，让不同国家标准的插头能够插入到插座中一样。
主要角色：
- Client：只依赖 Target 接口
- Target：客户端期望的抽象（协议/ABC）
- Adaptee：已存在但接口不兼容的类/函数
- Adapter：将 Adaptee 包装成 Target
适用场景
- 三方库/遗留代码接口不匹配
- 需要对一批类做 统一抽象（例如统一日志、统一存储）
- 开闭原则：扩展而非修改旧代码
优缺点
- 优点：
- 可以让不兼容的接口协同工作
- 提高了类的复用性
- 增加了类的透明性
- 灵活性好
- 缺点：
- 过多使用适配器会使系统变得复杂
- 某些语言不支持多重继承（但Python支持）
from abc import ABC, abstractmethod
# 目标接口
class Target(ABC):
"""客户期望的接口"""
@abstractmethod
def request(self) -> str:
pass
# 适配者
class Adaptee:
"""需要被适配的现有类"""
def specific_request(self) -> str:
return "Adaptee's specific request"
# 适配器
class Adapter(Target):
"""将Adaptee接口转换为Target接口"""
def __init__(self, adaptee: Adaptee) -> None:
self._adaptee = adaptee
def request(self) -> str:
return f"Adapter: (TRANSLATED) {self._adaptee.specific_request()}"
# 客户端代码
def client_code(target: Target) -> None:
"""客户端代码只与Target接口交互"""
print(target.request())
if __name__ == "__main__":
adaptee = Adaptee()
adapter = Adapter(adaptee)
client_code(adapter)
# 输出: Adapter: (TRANSLATED) Adaptee's specific request
实际应用案例：支付系统适配
from abc import ABC, abstractmethod
from typing import Tuple
# 目标接口：统一的支付接口
class PaymentGateway(ABC):
"""统一的支付网关接口"""
@abstractmethod
def process_payment(self, amount: float, currency: str) -> Tuple[bool, str]:
pass
# 适配者1：支付宝支付
class Alipay:
"""支付宝支付（现有系统）"""
def alipay_payment(self, rmb_amount: float) -> str:
"""支付宝只接受人民币支付"""
return f"Alipay success: ￥{rmb_amount:.2f}"
# 适配者2：PayPal支付
class PayPal:
"""PayPal支付（现有系统）"""
def make_payment(self, usd_amount: float) -> str:
"""PayPal只接受美元支付"""
return f"PayPal success: ${usd_amount:.2f}"
# 支付宝适配器
class AlipayAdapter(PaymentGateway):
def __init__(self, alipay: Alipay):
self._alipay = alipay
def process_payment(self, amount: float, currency: str) -> Tuple[bool, str]:
if currency != "CNY":
return False, "Alipay only accepts CNY"
result = self._alipay.alipay_payment(amount)
return True, result
# PayPal适配器
class PayPalAdapter(PaymentGateway):
def __init__(self, paypal: PayPal):
self._paypal = paypal
def process_payment(self, amount: float, currency: str) -> Tuple[bool, str]:
if currency != "USD":
return False, "PayPal only accepts USD"
# 这里可以添加汇率转换逻辑
result = self._paypal.make_payment(amount)
return True, result
# 客户端代码
def process_order_payment(gateway: PaymentGateway, amount: float, currency: str):
"""处理订单支付"""
success, message = gateway.process_payment(amount, currency)
if success:
print(f"Payment successful: {message}")
else:
print(f"Payment failed: {message}")
if __name__ == "__main__":
# 创建支付服务实例
alipay = Alipay()
paypal = PayPal()
# 创建适配器
alipay_adapter = AlipayAdapter(alipay)
paypal_adapter = PayPalAdapter(paypal)
# 处理支付
process_order_payment(alipay_adapter, 100.50, "CNY")
# 输出: Payment successful: Alipay success: ￥100.50
process_order_payment(paypal_adapter, 50.75, "USD")
# 输出: Payment successful: PayPal success: $50.75
process_order_payment(alipay_adapter, 100.50, "USD")
# 输出: Payment failed: Alipay only accepts CNYclassDiagram
class Target {
<<interface>>
+request() str
}
class Adaptee {
+specific_request() str
}
class Adapter {
-_adaptee: Adaptee
+request() str
}
class Client {
+client_code(Target)
}
Target <|.. Adapter
Adapter *-- Adaptee
Client --> Target
note for Adapter "将Adaptee的接口转换为Target接口"桥接模式（Bridge Pattern）
组合模式（Composite Pattern）
装饰器模式（Decorator Pattern）
外观模式（Facade Pattern）
享元模式（Flyweight Pattern）
代理模式（Proxy Pattern）
行为型设计模式（Behavioral Patterns）
行为型模式用于描述对象之间的交互和职责分配，主要关注对象之间的通信。
这些模式可以优化对象之间的交互逻辑，提高代码的可维护性和可扩展性。常见的行为型模式包括：
责任链模式（Chain of Responsibility Pattern）
使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。
将这些对象连成一条链，并沿着这条链传递请求，直到有一个对象处理它为止。
角色
- Handler(抽象处理者): 定义处理请求的接口，通常包含一个处理方法和一个设置后继者的方法
- ConcreteHandler(具体处理者): 实现抽象处理者的接口，处理它负责的请求，可以访问其后继者
- Client(客户端): 创建处理链并向链上的具体处理者对象提交请求
分类
- 纯责任链模式: 请求必须被某个处理者处理，不允许未被处理的情况
- 不纯责任链模式: 允许请求不被任何处理者处理而直接结束
适用场景
- 有多个对象可以处理同一请求，但具体由哪个对象处理在运行时自动确定
- 想在不明确指定接收者的情况下，向多个对象中的一个提交请求
- 可动态指定一组对象处理请求
优缺点
- 优点：
- 降低耦合度：请求发送者无需知道具体哪个对象会处理请求
- 增强灵活性：可以动态地重新组织链或改变处理顺序
- 简化对象：处理者只需保持一个后继引用，不需保持所有候选接收者的引用
- 缺点：
- 请求可能未被处理（在不纯责任链中）
- 较难观察运行时的处理流程
- 可能影响性能（请求需要遍历整个链）
实现步骤
定义抽象处理者接口：
- 创建Handler抽象基类
- 定义set_next()方法用于设置下一个处理者
- 定义handle()抽象方法用于处理请求
实现具体处理者：
- 创建继承自Handler的具体处理者类
- 实现handle()方法，包含业务逻辑
- 如果不能处理请求，调用_pass_to_next()传递给下一个处理者
构建处理链：
- 实例化各个具体处理者
- 使用set_next()方法将它们链接起来
- 可以灵活调整链的顺序
客户端调用：
- 客户端只需知道链的第一个处理者
- 将请求发送给链的第一个处理者
- 无需关心具体由哪个处理者处理
处理流程：
- 请求从链首开始传递
- 每个处理者决定是否处理该请求
- 如果不处理，则传递给下一个处理者
- 直到请求被处理或到达链尾
最佳实践
- 控制链的长度：避免过长的处理链影响性能
- 合理设置默认行为：明确链尾的处理方式（处理或丢弃）
- 动态修改链结构：运行时动态添加或移除处理者
- 避免循环引用：确保链是单向的，没有循环
- 考虑性能优化：对于频繁调用的链，可以考虑缓存策略
flowchart TD
Start[客户端调用client_code] --> Loop[遍历请求列表]
Loop --> CurrentReq[当前请求]
CurrentReq --> HandlerA[Handler A.handle]
HandlerA --> CondA{request == 'A'?}
CondA -->|是| ProcessA[返回处理结果]
CondA -->|否| PassA[调用_pass_to_next]
PassA --> HandlerB[Handler B.handle]
HandlerB --> CondB{request == 'B'?}
CondB -->|是| ProcessB[返回处理结果]
CondB -->|否| PassB[调用_pass_to_next]
PassB --> HandlerC[Handler C.handle]
HandlerC --> CondC{request == 'C'?}
CondC -->|是| ProcessC[返回处理结果]
CondC -->|否| Unhandled[返回未处理]
ProcessA --> Output[打印结果]
ProcessB --> Output
ProcessC --> Output
Unhandled --> Output
Output --> Loop链构建阶段
flowchart LR
A[创建HandlerA] --> B[创建HandlerB]
B --> C[创建HandlerC]
A -->|set_next| B
B -->|set_next| C请求处理阶段
flowchart TD
Start --> HandlerA
HandlerA -->|A| ResultA
HandlerA -->|其他| HandlerB
HandlerB -->|B| ResultB
HandlerB -->|其他| HandlerC
HandlerC -->|C| ResultC
HandlerC -->|其他| Unhandled命令模式（Command Pattern）
解释器模式（Interpreter Pattern）
迭代器模式（Iterator Pattern）
中介者模式（Mediator Pattern）
备忘录模式（Memento Pattern）
观察者模式（Observer Pattern）
状态模式（State Pattern）
策略模式（Strategy Pattern）
策略模式(Strategy Pattern)定义了一系列算法族，将每个算法分别封装起来，让它们之间可以互相替换。
策略模式让算法的变化独立于使用算法的客户端。
主要角色
- Context(上下文): 持有一个策略类的引用，通过策略接口与具体策略交互
- Strategy(策略接口): 定义所有支持的算法的公共接口
- ConcreteStrategy(具体策略): 实现策略接口的具体算法类
适用场景
- 一个系统需要动态地在几种算法中选择一种
- 有多个条件语句的相同行为，可以封装成策略
- 需要隐藏算法实现细节
- 算法使用频率或复杂度可能变化，需要灵活切换
优缺点
- 优点：
- 算法可以自由切换
- 避免使用多重条件判断
- 扩展性好（增加新策略很容易）
- 符合开闭原则
- 算法可以复用
- 缺点：
- 客户端必须知道所有的策略类
- 策略类数量可能增多
- 所有策略类都需要对外暴露
classDiagram
class Context {
-strategy: Strategy
+set_strategy(strategy: Strategy)
+execute_strategy()
}
class Strategy {
<<interface>>
+execute()
}
class ConcreteStrategyA {
+execute()
}
class ConcreteStrategyB {
+execute()
}
Context o--> Strategy
Strategy <|.. ConcreteStrategyA
Strategy <|.. ConcreteStrategyB步骤说明
- 定义策略接口：
- 创建抽象基类或接口，定义所有策略必须实现的方法
- 示例中的SortStrategy和PaymentStrategy
- 实现具体策略：
- 为每个算法创建具体策略类
- 实现策略接口中定义的方法
- 示例中的各种排序策略和支付策略
- 创建上下文类：
- 持有策略对象的引用
- 提供设置策略的方法
- 提供执行策略的方法（委托给当前策略对象）
- 示例中的Sorter和PaymentProcessor
- 客户端使用：
- 创建上下文对象
- 根据需要设置具体策略
- 调用上下文执行方法
- 示例中的main()和checkout()函数
支付策略工厂
- 支付策略接口：定义统一的支付处理方法
- 具体支付策略：实现各种支付方式的具体逻辑
- 支付策略工厂：负责创建和管理支付策略实例
- 支付上下文：执行支付操作，与具体策略解耦
classDiagram
class IPaymentStrategy {
<<interface>>
+process_payment(PaymentRequest) PaymentResult
}
class CreditCardStrategy
class PayPalStrategy
class CryptoStrategy
class BankTransferStrategy
class PaymentStrategyFactory {
-strategies: dict
+register_strategy(type:str, strategy:IPaymentStrategy)
+get_strategy(type:str) IPaymentStrategy
}
class PaymentProcessor {
-factory: PaymentStrategyFactory
+process_payment(type:str, request:PaymentRequest) PaymentResult
}
IPaymentStrategy <|.. CreditCardStrategy
IPaymentStrategy <|.. PayPalStrategy
IPaymentStrategy <|.. CryptoStrategy
IPaymentStrategy <|.. BankTransferStrategy
PaymentProcessor --> PaymentStrategyFactory
PaymentStrategyFactory --> IPaymentStrategy模板方法模式（Template Method Pattern）
访问者模式（Visitor Pattern）
On this page
- Design Pattern
- 创建型设计模式（Creational Patterns）
- 单例模式（Singleton Pattern）
- 工厂方法模式（Factory Method Pattern）
- 抽象工厂模式（Abstract Factory Pattern）
- 建造者模式（Builder Pattern）
- 原型模式（Prototype Pattern）
- 结构型设计模式（Structural Patterns）
- 适配器模式（Adapter Pattern）
- 桥接模式（Bridge Pattern）
- 组合模式（Composite Pattern）
- 装饰器模式（Decorator Pattern）
- 外观模式（Facade Pattern）
- 享元模式（Flyweight Pattern）
- 代理模式（Proxy Pattern）
- 行为型设计模式（Behavioral Patterns）
- 责任链模式（Chain of Responsibility Pattern）
- 命令模式（Command Pattern）
- 解释器模式（Interpreter Pattern）
- 迭代器模式（Iterator Pattern）
- 中介者模式（Mediator Pattern）
- 备忘录模式（Memento Pattern）
- 观察者模式（Observer Pattern）
- 状态模式（State Pattern）
- 策略模式（Strategy Pattern）
- 模板方法模式（Template Method Pattern）
- 访问者模式（Visitor Pattern）