PHP策略模式消除if

wen PHP项目 2026-08-11 2

本文目录导读：

PHP策略模式消除if

文章标题：PHP策略模式：用多态优雅消灭业务代码里的“if地狱”
目录导读

PHP策略模式：用多态优雅消灭业务代码里的“if地狱”

目录导读

一个让所有PHP开发者头疼的“if”场景
什么是策略模式：定义与核心角色拆解
实战对比：从“if/switch”到“策略类”的重构过程
PHP代码案例：支付渠道选择的完整落地
策略模式的“三驾马车”：上下文、策略接口、具体策略
高级技巧：如何结合容器与注解实现零配置注册
常见误区与性能考量：什么时候不该用策略模式
问答环节：解决你对“消除if”的最后疑虑
拥抱变化，从“删掉第一个if”开始

引言：一个让所有PHP开发者头疼的“if”场景

在真实的电商系统中，订单支付逻辑往往伴随着数量惊人的条件分支，请看下面这段“经典”代码：

public function pay($order, $type) {
    if ($type == 'alipay') {
        // 50行支付宝签名、调用逻辑
    } elseif ($type == 'wechat') {
        // 50行微信API调用逻辑
    } elseif ($type == 'unionpay') {
        // 50行银联XML解析逻辑
    } elseif ($type == 'balance') {
        // 余额扣减逻辑
    } else {
        throw new \Exception("未知支付方式");
    }
    // 后续统一处理订单状态
}

这段代码初看无碍，但一旦新增“PayPal”支付，你被迫修改这个已经稳定运行的方法。每次修改都意味着回归测试整个支付流程，这就是典型的“违反开闭原则”。PHP策略模式正是为了终结这种“if/else”不断膨胀的噩梦而生。

什么是策略模式：定义与核心角色拆解

策略模式（Strategy Pattern）属于行为型设计模式，其核心定义是：定义一系列算法，将每个算法封装起来，并使它们可以互相替换,它让算法的变化独立于使用算法的客户程序。

在这个模式中,有三个核心角色：

策略接口（Strategy）：定义了一个公共的算法执行方法（如 pay(array $order)）。
具体策略（ConcreteStrategy）：实现了策略接口，如 AlipayStrategy、WechatStrategy,各自封装了不同的支付算法。
上下文（Context）：持有一个策略对象的引用，负责将客户端的请求委派给策略对象,它屏蔽了高层模块对底层策略的直接依赖。

实战对比：从“if/switch”到“策略类”的重构过程

我们以上述支付代码为例,进行重构。

第一步：创建策略接口

interface PaymentStrategy {
    public function pay(array $order): void;
}

第二步：创建具体策略

class AlipayStrategy implements PaymentStrategy {
    public function pay(array $order): void {
        // 特定于支付宝的验签、请求网关逻辑
        echo "使用支付宝支付：" . $order['amount'] . "元\n";
    }
}
class WechatStrategy implements PaymentStrategy {
    public function pay(array $order): void {
        // 特定于微信的JSAPI或Native调用
        echo "使用微信支付：" . $order['amount'] . "元\n";
    }
}

第三步：创建上下文类（支付处理类）

class PaymentContext {
    private PaymentStrategy $strategy;
    // 关键：通过构造函数或setter注入具体策略
    public function __construct(PaymentStrategy $strategy) {
        $this->strategy = $strategy;
    }
    public function executePayment(array $order): void {
        // 可能在这里执行一些通用的日志、事务操作
        $this->strategy->pay($order);
    }
}

第四步：客户端调用（替代原始if）

// 原本： $payment = new PaymentService(); $payment->pay($order, 'alipay');
$strategy = new AlipayStrategy(); // 这行代码如何获得？下面会有高级答案
$context = new PaymentContext($strategy);
$context->executePayment($order);

通过上述重构，那个巨大的if/else块被完全拆解为多个独立的类，新增支付方式，只需新增类并传入上下文，核心业务类无需再变动。

PHP代码案例：支付渠道选择的完整落地

在实际高并发场景中，我们还需要一个“策略工厂”来消除客户端那个唯一的if（即new AlipayStrategy()）,我们可以结合数组映射：

class PaymentStrategyFactory {
    private array $strategies = [
        'alipay' => AlipayStrategy::class,
        'wechat' => WechatStrategy::class,
        // 'paypal' => PaypalStrategy::class
    ];
    public function create(string $type): PaymentStrategy {
        if (!isset($this->strategies[$type])) {
            throw new \InvalidArgumentException("不支持的支付类型: {$type}");
        }
        $class = $this->strategies[$type];
        return new $class();
    }
}
// 使用：
$factory = new PaymentStrategyFactory();
$context = new PaymentContext($factory->create($order['pay_type']));
$context->executePayment($order);

这种基于“映射表”的写法，替代了原始的elseif判断，且保持了O(1)的时间复杂度。这里唯一的isset判断，已经是你无法避免的合法边界检查了。

策略模式的“三驾马车”：上下文、策略接口、具体策略

请务必理解这几个概念的区别：

上下文不是“上帝类”，它只是知道如何与算法交互,它不关心算法具体如何实现。
策略接口是契约，是解耦的关键，没有接口,策略模式就退化为简单的类实例化。
具体策略必须是“纯函数”式的，提供独立的算法,不应依赖其他策略的状态。

高级技巧：如何结合容器与注解实现零配置注册

在大型框架（如Laravel、Symfony）中，我们更推荐利用依赖注入容器（DIC）自动注册策略，通过给策略类打上注解（Attribute）,在框架启动时自动收集到工厂中。

#[\Attribute]
class PaymentType {
    public function __construct(public string $key) {}
}
#[PaymentType(key: 'alipay')]
class AlipayStrategy implements PaymentStrategy { /* ... */ }
#[PaymentType(key: 'wechat')]
class WechatStrategy implements PaymentStrategy { /* ... */ }

然后通过反射扫描整个目录，构建$map = ['alipay' => AlipayStrategy::class]，这样，即使你新增了策略类，也无需修改工厂的数组，彻底做到了“开闭原则”的极致。

常见误区与性能考量：什么时候不该用策略模式

误区：为了一个if判断就建三个类和接口，这是过度设计，如果分支固定且不超过2个，简短的if更易读。
性能：策略模式本身不引入性能开销，但过度使用反射或复杂工厂会有微乎其微的损耗，在高频调用下，建议使用静态映射缓存（如opcache.preload）。
不要滥用：如果策略需要大量共享上下文状态,建议改为状态模式或模板方法模式。

问答环节：解决你对“消除if”的最后疑虑

Q1：我用了策略模式，但客户端不还是有那个isset来判断吗？算什么消除？ A：是的，你确实无法彻底消灭“识别创建依据”的if，我们消除的是业务逻辑算法内部的复杂条件嵌套，那个映射表的isset是必要的入场券检查，属于“类型防护”而非业务处理，真正消灭的是elseif链中的千百行代码。

Q2：每个策略类里可能也有重复的代码，怎么办？ A：这正是考验抽象能力的地方，使用“模板方法模式”或“抽象类”提取公共骨架，所有支付策略都需要记录日志，可以将pay方法定义为final，内部调用抽象方法executePayment,这样公共代码只写一次。

Q3：策略模式在PHP 8中有什么新特性加持吗？ A：PHP 8的构造函数属性提升（public function __construct(private array $config) {}）可以减少样板代码。枚举（Enum） 可以作为策略工厂的键,避免魔法字符串。

拥抱变化，从“删掉第一个if”开始

PHP策略模式不是银弹，但它是治理核心业务代码复杂度的重要工具，它教会我们用组合替代继承，用多态替代条件，当你下次看到不断膨胀的switch(true)时，请想象一下那背后的多个策略类，从今天起，尝试把第一个支付或者运费计算的if拆解为策略类，你会体验到“开闭原则”带来的安全性——新增功能不再破坏旧代码,这就是设计模式真正的魅力。

打开你的代码编辑器，找出那个最长的if,开始重构吧。