工厂模式 vs 策略模式：如何选择最适合业务扩展的设计方案？

第一章：工厂模式 vs 策略模式：核心概念与本质区别

工厂模式的核心思想

工厂模式是一种创建型设计模式，其主要目的是将对象的创建过程封装起来，使客户端代码与具体类解耦。通过定义一个创建对象的接口，但由子类决定实例化哪一个类，工厂模式实现了“延迟到子类实例化”的机制。

• 适用于对象创建逻辑复杂或需要统一管理的场景
• 典型实现包括简单工厂、工厂方法和抽象工厂
• 关注的是“如何创建对象”

// 工厂模式示例：支付方式创建
type Payment interface {
    Pay(amount float64) string
}

type Alipay struct{}

func (a *Alipay) Pay(amount float64) string {
    return fmt.Sprintf("支付宝支付 %.2f 元", amount)
}

type PaymentFactory struct{}

func (pf *PaymentFactory) Create(paymentType string) Payment {
    switch paymentType {
    case "alipay":
        return &Alipay{}
    default:
        panic("不支持的支付方式")
    }
}

策略模式的核心思想

策略模式属于行为型设计模式，旨在定义一系列算法或行为，并将它们封装在独立的类中，使得它们可以互相替换，而不影响客户端使用。

• 适用于多种算法共存且需动态切换的场景
• 强调“算法与使用分离”
• 关注的是“如何执行一个动作”

对比维度	工厂模式	策略模式
设计类型	创建型	行为型
核心目的	创建对象	封装算法
变化点	对象类型	行为逻辑

graph TD A[客户端] -- 使用 --> B(策略上下文) B -- 委托 --> C[具体策略A] B -- 委托 --> D[具体策略B] B -- 可替换 --> E[策略接口]

第二章：工厂模式的深入解析与Java实现

2.1 工厂模式的设计动机与适用场景

在面向对象设计中，直接在客户端代码中使用 new 创建对象会导致类之间的紧耦合。工厂模式通过将对象的创建过程封装到一个独立的方法或类中，实现创建逻辑与使用逻辑的分离。

设计动机

当系统需要支持多种同类产品（如不同数据库连接、支付网关）时，若每新增一种类型都需修改客户端代码，将违反开闭原则。工厂模式提供统一接口创建实例，降低维护成本。

典型应用场景

• 需要根据配置或环境动态决定实例类型的场景
• 对象创建过程复杂，涉及依赖注入或初始化逻辑
• 希望屏蔽产品类的具体实现，仅暴露抽象接口

type Payment interface {
    Pay(amount float64) string
}

type Alipay struct{}

func (a *Alipay) Pay(amount float64) string {
    return fmt.Sprintf("支付宝支付 %.2f 元", amount)
}

type PaymentFactory struct{}

func (f *PaymentFactory) Create(paymentType string) Payment {
    switch paymentType {
    case "alipay":
        return &Alipay{}
    default:
        return nil
    }
}

上述代码中， Create 方法根据传入类型返回对应的支付实现，客户端无需知晓具体构造细节，仅通过工厂获取可用实例，提升了系统的可扩展性与可维护性。

2.2 简单工厂模式的Java代码实现

核心角色定义

简单工厂模式包含三个核心角色：产品接口、具体产品类和工厂类。工厂类通过静态方法根据参数决定实例化哪个具体产品。

代码实现

// 产品接口
interface Fruit {
    void grow();
}

// 具体产品类
class Apple implements Fruit {
    public void grow() {
        System.out.println("Apple is growing...");
    }
}

class Banana implements Fruit {
    public void grow() {
        System.out.println("Banana is growing...");
    }
}

// 工厂类
class FruitFactory {
    public static Fruit getFruit(String type) {
        if ("apple".equalsIgnoreCase(type)) {
            return new Apple();
        } else if ("banana".equalsIgnoreCase(type)) {
            return new Banana();
        }
        throw new IllegalArgumentException("Unknown fruit type");
    }
}

上述代码中， FruitFactory.getFruit() 根据传入的字符串类型返回对应的水果实例。客户端无需关心创建逻辑，仅通过工厂获取对象，实现了创建与使用的分离。

2.3 工厂方法模式的结构与扩展性分析

工厂方法模式通过定义一个用于创建对象的接口，但由子类决定实例化的类是哪一个。该模式将对象的实例化推迟到具体子类，提升了系统的可扩展性。

核心结构解析

主要角色包括抽象工厂、具体工厂、抽象产品和具体产品。每个具体工厂对应一种具体产品的创建逻辑。

• 抽象工厂（Factory）：声明创建产品对象的方法
• 具体工厂（ConcreteFactory）：实现创建特定产品实例的逻辑
• 抽象产品（Product）：定义产品对象的接口
• 具体产品（ConcreteProduct）：实现产品接口的具体对象

代码示例与分析

type Product interface {
    GetName() string
}

type ConcreteProduct struct{}

func (p *ConcreteProduct) GetName() string {
    return "Product A"
}

type Factory interface {
    CreateProduct() Product
}

type ConcreteFactory struct{}

func (f *ConcreteFactory) CreateProduct() Product {
    return &ConcreteProduct{}
}

上述代码展示了工厂方法的基本实现。通过接口隔离创建逻辑，新增产品时只需添加新的具体工厂和产品类，无需修改原有代码，符合开闭原则。

扩展性优势

特性	说明
可维护性	职责分离，便于定位问题
可扩展性	新增产品不影响现有结构

2.4 抽象工厂模式在多产品族中的应用

在处理多个相关或依赖对象的创建时，抽象工厂模式提供了一种不依赖具体类的解决方案，尤其适用于存在多个产品族的场景。

核心结构与角色

• 抽象工厂（Abstract Factory）：声明创建一组产品的方法
• 具体工厂（Concrete Factory）：实现创建特定产品族的逻辑
• 抽象产品（Abstract Product）：定义产品接口
• 具体产品（Concrete Product）：实现抽象产品的具体类

代码示例

type GUIFactory interface {
    CreateButton() Button
    CreateCheckbox() Checkbox
}

type WinFactory struct{}

func (f *WinFactory) CreateButton() Button { return &WinButton{} }
func (f *WinFactory) CreateCheckbox() Checkbox { return &WinCheckbox{} }

上述代码定义了一个跨平台UI组件工厂， WinFactory 能统一创建属于Windows风格的产品族，确保界面元素风格一致。通过接口隔离创建逻辑，客户端无需感知具体类型，提升系统可扩展性。

2.5 工厂模式在实际业务中的性能与维护考量

在高并发场景下，工厂模式的创建逻辑可能成为性能瓶颈。频繁反射或条件判断会增加对象初始化开销。

避免反射创建的优化策略

var handlerMap = map[string]Handler{
    "email":  &EmailHandler{},
    "sms":    &SMSHandler{},
}

func CreateHandler(typ string) Handler {
    if h, exists := handlerMap[typ]; exists {
        return h
    }
    panic("unsupported type")
}

通过预注册实例映射替代运行时反射，降低每次创建的计算成本，提升响应速度。

可维护性设计建议

• 将工厂逻辑集中管理，避免散落在多处
• 使用接口隔离具体实现，增强扩展性
• 结合依赖注入框架减少手动工厂调用

第三章：策略模式的架构设计与实践

3.1 策略模式的核心组成与运行机制

策略模式通过分离算法逻辑与使用逻辑，实现行为的灵活替换。其核心由三部分构成：策略接口、具体策略类和上下文对象。

策略接口定义

所有具体策略需实现统一接口，确保调用一致性：

type PaymentStrategy interface {
    Pay(amount float64) string
}

该接口声明了支付行为的通用方法，参数 amount 表示交易金额，返回值为操作结果描述。

具体策略实现

不同支付方式（如支付宝、微信）分别实现接口：

type Alipay struct{}

func (a *Alipay) Pay(amount float64) string {
    return fmt.Sprintf("使用支付宝支付 %.2f 元", amount)
}

每个实现封装独立的业务逻辑，便于扩展与维护。

上下文调度机制

上下文持有策略引用，动态委托执行：

组件	职责
PaymentContext	管理当前策略实例
SetStrategy()	运行时切换策略
ExecutePay()	转发请求至具体策略

3.2 基于接口的策略定义与动态切换实现

在微服务架构中，基于接口的策略模式能够有效解耦业务逻辑与具体实现。通过定义统一的行为契约，系统可在运行时动态切换不同策略。

策略接口设计

type DataSyncStrategy interface {
    Sync(data []byte) error
    GetName() string
}

该接口规范了数据同步行为，GetName 方法用于标识策略类型，便于路由判断。

多实现注册与切换

• HTTPSyncStrategy：适用于跨网络同步
• KafkaSyncStrategy：支持异步消息队列
• LocalFileSyncStrategy：用于本地文件落地

通过依赖注入容器，结合配置中心实时加载策略实例，实现无缝切换。

3.3 策略模式在算法封装与业务规则解耦中的优势

策略模式通过将不同算法封装为独立的策略类，使业务逻辑与具体实现分离，提升系统的可维护性与扩展性。

核心结构设计

系统定义统一策略接口，各类算法实现该接口，上下文动态引用具体策略实例。

type PaymentStrategy interface {
    Pay(amount float64) string
}

type CreditCard struct{}

func (c *CreditCard) Pay(amount float64) string {
    return fmt.Sprintf("Paid %.2f via Credit Card", amount)
}

type PayPal struct{}

func (p *PayPal) Pay(amount float64) string {
    return fmt.Sprintf("Paid %.2f via PayPal", amount)
}

上述代码中， PaymentStrategy 接口抽象支付行为， CreditCard 和 PayPal 实现不同支付逻辑。上下文可通过注入不同策略对象执行对应算法。

运行时动态切换

• 避免使用条件判断硬编码算法路径
• 新增策略无需修改现有业务代码
• 便于单元测试与策略复用

第四章：模式对比与业务场景选型指南

4.1 创建型 vs 行为型：本质设计目标差异

创建型设计模式聚焦于对象的实例化过程，旨在解耦系统对具体类的依赖。典型如工厂方法、单例和建造者模式，它们通过封装对象创建逻辑提升灵活性与可维护性。

核心关注点对比

• 创建型模式：解决“如何创建对象”问题，强调对象生成的控制权分离。
• 行为型模式：解决“对象间如何通信与协作”问题，关注职责分配与算法封装。

代码示例：工厂方法 vs 策略模式

// 创建型：工厂方法
public interface Product { void use(); }
public interface Factory {
    Product createProduct();
}

上述代码将对象创建延迟到子类，实现创建逻辑与使用逻辑解耦。

// 行为型：策略模式
public interface Strategy {
    void execute();
}
public class Context {
    private Strategy strategy;
    public void setStrategy(Strategy s) { this.strategy = s; }
    public void run() { strategy.execute(); }
}

策略模式封装可变行为，使算法独立于客户端变化，体现行为委派思想。

4.2 扩展性对比：新增类型对两类模式的影响

在软件架构中，新增数据类型对工厂模式与策略模式的扩展性影响显著不同。

工厂模式的扩展成本

每新增一种产品类型，通常需要扩展工厂类或添加新的具体工厂。以简单工厂为例：

public class ShapeFactory {
    public Shape create(String type) {
        if ("circle".equals(type)) return new Circle();
        if ("square".equals(type)) return new Square();
        // 新增类型需修改此处
        throw new IllegalArgumentException("Unknown type");
    }
}

该实现违反开闭原则，每次新增图形类型都需修改工厂逻辑，导致维护成本上升。

策略模式的天然扩展优势

策略模式通过接口聚合行为，新增策略无需修改上下文：

• 定义统一策略接口
• 每个新算法独立实现接口
• 运行时动态注入，解耦明确

因此，在频繁新增处理类型的场景下，策略模式具备更优的可扩展性与维护性。

4.3 实际案例中混合使用工厂与策略的协同方案

在支付系统设计中，常需根据用户选择动态切换支付逻辑。通过工厂模式创建策略实例，结合策略模式执行算法，可实现高度解耦。

核心接口定义

type PaymentStrategy interface {
    Pay(amount float64) string
}

type PaymentFactory struct{}

func (f *PaymentFactory) GetPaymentMethod(method string) PaymentStrategy {
    switch method {
    case "alipay":
        return &Alipay{}
    case "wechat":
        return &WechatPay{}
    default:
        return nil
    }
}

工厂类 PaymentFactory 根据传入字符串返回对应的支付策略实例，避免客户端直接依赖具体实现。

策略实现与调用流程

• 客户端请求支付方式（如 "alipay"）
• 工厂生成对应策略对象
• 调用统一 Pay 方法完成业务

该结构支持后续扩展新支付方式，无需修改原有代码，符合开闭原则。

4.4 如何根据业务变化频率选择最优模式

在系统设计中，业务变化频率是决定架构模式的关键因素。高频变更的业务适合事件驱动架构，低频稳定业务则更适合请求响应模式。

典型场景分类

• 高频率变化：如订单状态更新，推荐使用消息队列解耦
• 中等频率变化：如用户资料修改，可采用CQRS模式分离读写
• 低频率变化：如静态配置管理，直接使用REST API即可

性能对比参考

模式	延迟	一致性	适用场景
事件驱动	低	最终一致	高频变更
REST同步	中	强一致	低频稳定

// 示例：事件发布逻辑
func PublishEvent(event OrderEvent) {
    payload, _ := json.Marshal(event)
    err := rabbitMQChannel.Publish(
        "order_exchange", // exchange
        event.Type,       // routing key
        false,            // mandatory
        false,            // immediate
        amqp.Publishing{
            ContentType: "application/json",
            Body:        payload,
        })
    if err != nil {
        log.Errorf("Publish failed: %v", err)
    }
}

该代码实现订单事件的异步发布，通过RabbitMQ解耦服务，适用于每秒数百次变更的高频业务场景。参数 mandatory设为false表示消息不可路由时将被丢弃，提升吞吐量。

第五章：总结与设计模式演进趋势

现代架构中的模式融合

在微服务与云原生架构普及的背景下，传统设计模式正与领域驱动设计（DDD）和事件驱动架构深度融合。例如，工厂模式常用于动态创建不同服务客户端实例：

type ClientFactory struct{}

func (f *ClientFactory) CreateClient(service string) ServiceClient {
    switch service {
    case "user":
        return &UserClient{endpoint: os.Getenv("USER_SVC")}
    case "order":
        return &OrderClient{endpoint: os.Getenv("ORDER_SVC")}
    default:
        panic("unsupported service")
    }
}

响应式编程中的观察者演化

响应式流（如Reactor、RxJS）将观察者模式提升至新层级。通过发布-订阅机制处理异步数据流，广泛应用于实时订单推送系统：

• 定义事件源（Publisher）触发状态变更
• 多个消费者（Subscriber）监听并执行业务逻辑
• 背压（Backpressure）机制防止资源过载

函数式编程对策略模式的替代

在Go或JavaScript中，高阶函数可直接传递行为，减少类层次冗余。如下所示，使用函数变量实现算法注入：

const retryStrategy = (fn, retries = 3) => async (...args) => {
  for (let i = 0; i < retries; i++) {
    try {
      return await fn(...args);
    } catch (err) {
      if (i === retries - 1) throw err;
    }
  }
};

设计模式工具化趋势

现代框架内置模式实现，降低手动编码成本。Spring Boot自动配置单例Bean，React Hooks封装状态逻辑复用，本质上是组合模式的函数化表达。下表列举典型框架对模式的支持：

设计模式	框架支持示例	应用场景
代理模式	Spring AOP	日志、权限拦截
建造者模式	Lombok @Builder	复杂对象构造