PHP 策略模式重构业务

wen PHP项目 2026-08-10 2

告别IF-ELSE地狱：用PHP策略模式重构复杂业务逻辑的实战指南

目录导读（Table of Contents）

业务之痛：为什么你的代码越来越像“意大利面条”？
模式初识：策略模式（Strategy Pattern）核心概念与UML解析
重构实战：从支付场景出发，手写PHP策略模式代码
进阶技巧：结合容器（Container）与注解，实现策略自动注册
陷阱与避坑：策略模式的常见误用场景及性能考量
互动问答（Q&A）：解决你在重构中最关心的5个问题

业务之痛：当“简单需求”遇上“复杂裂变”

在PHP业务开发中，我们经常遇到这样的场景：一个OrderService类里，堆满了if ($channel == 'alipay') {...} elseif ($channel == 'wechat') {...} elseif ($channel == 'credit_card') {...}，起初只有2个渠道，后来涨到了8个，每次新增支付方式，你都要动核心类，测试覆盖全量回归,开发效率极低。

PHP 策略模式重构业务

核心痛点：

违背开闭原则：新增功能需要修改旧代码,极易引入线上Bug。
逻辑臃肿：单个方法动辄几百行,代码可读性极差。
耦合严重：业务算法与调用方高度耦合,无法独立单元测试。

这时，策略模式便成为解决这类“算法族”频繁变动的首选方案。

模式初识：策略模式的核心思想

策略模式属于行为型设计模式，它的定义很精炼：定义一组算法，将每个算法都封装起来，并且使它们之间可以互换。

关键角色：

Context（上下文）：持有策略对象的引用，负责调用策略,但不关心具体实现。
Strategy（抽象策略）：定义算法家族的公共接口，通常是一个PHP interface。
ConcreteStrategy（具体策略）：实现接口的具体算法类。

核心价值：它将变化的算法与不变的调用逻辑分离,让算法可以独立于客户端演进。

重构实战：以支付渠道为例

假设我们有一个PaymentService，当前需要支持支付宝、微信和银行卡支付。

Step 1: 定义抽象策略接口

<?php
namespace App\Strategies\Payment;
interface PaymentStrategy
{
    /**
     * 统一支付入口
     * @param array $orderInfo
     * @return array [status, transaction_id, message]
     */
    public function pay(array $orderInfo): array;
}

Step 2: 实现具体策略（每个渠道一个类）

<?php
namespace App\Strategies\Payment;
use App\Gateways\AlipayGateway;
class AlipayStrategy implements PaymentStrategy
{
    public function __construct(private AlipayGateway $gateway)
    {}
    public function pay(array $orderInfo): array
    {
        // 调用支付宝特定SDK，处理签名、回调逻辑
        $response = $this->gateway->charge($orderInfo['amount'], $orderInfo['subject']);
        return [
            'status' => $response->isSuccess(),
            'transaction_id' => $response->getTradeNo(),
            'message' => $response->getMessage()
        ];
    }
}
// 注意：WechatStrategy 和 CreditCardStrategy 实现逻辑类似，但调用不同的SDK类。

Step 3: 重构Context（调用方/业务层）

原先的OrderService应该重构成一个持有策略的容器：

<?php
namespace App\Services;
use App\Strategies\Payment\PaymentStrategy;
class PaymentContext
{
    public function __construct(private PaymentStrategy $strategy)
    {}
    public function executePayment(array $orderData): array
    {
        // 前置逻辑：日志、订单状态校验
        $result = $this->strategy->pay($orderData);
        // 后置逻辑：通知、记录流水
        return $result;
    }
}

Step 4: 客户端调用（使用简单工厂或容器解析）

<?php
// 在Laravel中，可以利用容器自动注入
$strategy = match ($request->input('channel')) {
    'alipay' => app(AlipayStrategy::class),
    'wechat' => app(WechatStrategy::class),
    'credit_card' => app(CreditCardStrategy::class),
    default => throw new \InvalidArgumentException('Unsupported payment method'),
};
$context = new PaymentContext($strategy);
$result = $context->executePayment($orderData);

重构后收益：新增Patreon支付时，只需新增PatreonStrategy类，修改match分支或注册表即可，零侵入原有类。

进阶技巧：让策略更优雅

对于大型系统，手写match依然繁琐，我们可以利用PHP 8 Attribute + 容器Autowiring实现策略自动注册。

定义注解：

#[Attribute(Attribute::TARGET_CLASS)]
class PaymentChannel
{
    public function __construct(public string $channelName)
    {}
}

在策略类上使用：

#[PaymentChannel('alipay')]
class AlipayStrategy implements PaymentStrategy { ... }

通过反射构建映射：系统启动时扫描目录，通过反射获取属性，生成 ['alipay' => 'App\Strategies\Payment\AlipayStrategy'] 映射表，这样，上层业务只需根据channel从容器中取出对应策略实例，彻底消灭match分支。

陷阱与避坑：策略模式不是万能药

策略过多：如果算法不经常变化（比如只是参数不同），强行使用策略模式会导致类爆炸，此时应优先考虑模板方法模式或简单工厂。
状态管理：策略模式不管理内部状态，如果策略需要保持状态（如分页游标）,请将状态移到Context外部管理。
性能损耗：大量的动态解析（反射）在低版本PHP中较慢，但PHP 8+的JIT和Opcache已大幅缓解,且通常瓶颈不在策略调用上。

互动问答（Q&A）

Q1：策略模式和简单工厂模式有什么区别？

答：工厂模式属于创建型，关注“如何创建对象”；策略模式属于行为型，关注“算法的封装与替换”，通常在客户端中，先使用工厂选择合适的策略对象，再使用策略模式执行算法，二者常搭配使用,并不冲突。

Q2：如果策略类中有很多私有方法，会导致代码重复吗？

答：如果多个策略有公共逻辑（如日志记录、HTTP请求封装），可以创建一个抽象基类（AbstractClass），让具体策略继承，将公共方法下沉至基类,避免重复代码。

Q3：在Swoole/Workerman长驻内存环境下，策略对象需要单例吗？

答：强烈建议，策略对象通常是无状态的，不建议在属性中保存用户数据，通过容器将策略注册为单例（singleton）,可以大幅减少对象创建开销和GC压力。

Q4：能否用数组配置代替策略类？

答：可以，如果算法逻辑非常简单（如折扣计算），可以用配置数组 ['alipay'=>['rate'=>0.6]] 代替类，但一旦逻辑复杂（需要调用外部服务），数组配置将难以维护,此时类更佳。

Q5：策略模式一定比IF-ELSE性能差吗？

答：几乎不会，PHP中方法调用几十纳秒级别的开销，相比数据库查询（毫秒）和网络IO（微秒）可忽略不计，与其关注策略模式的微性能损耗,不如关注数据库索引和Redis缓存设计。

策略模式是PHP开发者从“面向过程”走向“面向接口”的关键一步，它不仅是代码结构的美化，更是对业务基线的封装，当你下次看到那一行行重复的if判断时，不妨尝试用策略模式重构，或许你会发现，复杂的业务逻辑也能像瑞士军刀一样，工具分明、随取随用。