策略设计模式降低代码圈复杂度的适用性及消除条件语句的疑问

1. 策略设计模式为何适用于降低代码的圈复杂度？ #

圈复杂度的核心计算依据是代码中的分支点数量（if/switch、循环等），分支越多，圈复杂度越高，代码越难维护和测试。

策略模式通过以下方式降低圈复杂度：

• 移除核心类的分支逻辑：把原本写在Context类里的条件分支判断（比如根据不同场景执行不同行为的if/switch），拆分成独立的Strategy实现类。Context类不再需要判断该用哪种行为，只需要依赖抽象的Strategy接口调用统一方法即可，这直接砍掉了Context类里的所有分支点。
• 单一职责拆分：每个Strategy类只实现一种具体行为，逻辑单一，自身的圈复杂度极低，不会出现多个分支嵌套的情况。
• 避免分支扩散：后续新增行为时，只需要新增一个Strategy实现类，不需要在原有代码里加新的else/switch case，不会导致圈复杂度随着功能迭代持续上升。

举个简单例子：
原来的Context代码（圈复杂度3）：

public class PaymentContext {
    public void pay(String type) {
        if (type.equals("alipay")) {
            // 支付宝支付逻辑
        } else if (type.equals("wechat")) {
            // 微信支付逻辑
        }
    }
}

用策略模式重构后，Context的圈复杂度变为1：

public class PaymentContext {
    private PaymentStrategy strategy;
    public PaymentContext(PaymentStrategy strategy) {
        this.strategy = strategy;
    }
    public void pay() {
        strategy.pay();
    }
}

public interface PaymentStrategy {
    void pay();
}

public class AliPayStrategy implements PaymentStrategy {
    public void pay() {
        // 支付宝支付逻辑
    }
}

public class WeChatPayStrategy implements PaymentStrategy {
    public void pay() {
        // 微信支付逻辑
    }
}

2. 上述多客户端场景是否就是该模式“消除条件语句”表述所指，还是我有所遗漏？ #

GoF提到的“消除条件语句”，核心是消除承载核心业务逻辑的Context类中的条件语句，而不是要求整个代码库完全没有任何条件分支。

你提到的多客户端场景是符合这个表述的一种情况，但不是唯一情况：

• 当存在多个客户端时，每个客户端直接创建对应的Strategy和Context组合，确实不需要任何条件分支，这是最理想的无分支场景。
• 但更多时候，单一客户端也可以通过其他方式避免条件分支的“转移”：比如用依赖注入框架自动注入所需的Strategy，或者把策略选择逻辑封装到专门的策略工厂类中，让业务代码（客户端）不需要处理分支判断。

GoF的表述重点是：把原本混杂在核心业务逻辑里的条件分支，从Context类中剥离出去——不管是转移到客户端、工厂类，还是通过DI框架处理，只要核心业务类（Context）不再有分支，就达成了“消除条件语句”的核心目的。你理解的多客户端场景是其中一种，但不要局限于此，核心是让核心业务类摆脱分支逻辑的困扰。

内容的提问来源于stack exchange，提问作者Niek Beijloos