这个java案例如何看这次二过一配合？

wen java案例 2026-08-16 2

Java策略模式实战：从“二过一配合”看代码的团队协作艺术

目录导读

开篇：当足球战术遇上Java设计模式
案例拆解：什么是“二过一配合”式代码？
核心代码演示：策略模式与依赖注入的化学反应
深度问答：为什么说好的架构像默契的传球？
实战启示：如何训练你的代码“团队意识”
代码如球赛，配合赢天下

开篇：当足球战术遇上Java设计模式

想象一下，绿茵场上，前锋A持球吸引防守，前锋B迅速斜插空当，A一脚精准直塞，B接球后直接打门——这就是经典的“二过一”配合，在Java开发中，我们常遇到类似的场景：主模块持有数据，需要调用辅助模块的方法，而辅助模块又需要主模块的上下文才能执行，如果两者硬编码耦合，就像两个球员永远只站在原地传球，一旦对手（需求变更）贴防，整个球队（系统）就会瘫痪。

这个java案例如何看这次二过一配合？

最近在重构一个支付系统时，我看到了一个教科书级的“二过一”案例：PaymentService需要调用RiskControlService校验风控，但风控规则经常变，最初的代码像一潭死水，if-else堆了300行，后来用策略模式+函数式接口重构，让两个服务通过一个Context传递，瞬间变成了流畅的“撞墙配合”，这篇文章我们就用这个案例，看看代码里的“二过一”为什么值得深度学习。

案例拆解：什么是“二过一配合”式代码？

“二过一”在代码中的定义：两个独立模块（PlayerA与PlayerB）不直接通信，而是通过一个中间载体（Context或委托对象）完成数据交换与逻辑调用，这正好映射了设计模式中的中介者模式与策略模式的结合。

原始代码痛点（失败的“单打独斗”）：

public class PaymentService {
    public void pay(Order order) {
        // 硬编码风控规则1
        if (order.getAmount() > 10000) { checkLevel1(); }
        // 硬编码风控规则2
        if (order.getUser().isNewUser()) { checkLevel2(); }
        // 后续逻辑...
    }
}

这就像前锋A拿到球后，既要做假动作又要找射门角度，最终被后卫（维护成本）断球。

重构后代码（成功的“二过一”）：

public class PaymentService {
    private RiskControlStrategy strategy; // 策略接口
    public void pay(Order order, RiskContext context) {
        // 传球给策略对象
        boolean passed = strategy.check(context);
        if (passed) { // 接球后射门
            executePayment(order);
        }
    }
}
@FunctionalInterface
interface RiskControlStrategy {
    boolean check(RiskContext ctx);
}

关键点：RiskContext就是那个“传球路线”，它封装了Order、用户信息、金额等所有变量。PaymentService不再关心规则，只负责“传球”给strategy——这就像A球员把球交给B球员，B再根据场上形势（策略实现）决定怎么处理。

核心代码演示：策略模式与依赖注入的化学反应

为了更贴近“二过一”，我们再加一个中间层——规则引擎工厂。

// 上下文类（足球：球）
public class RiskContext {
    private Order order;
    private User user;
    private LocalDateTime time;
    // getter/setter...
}
// 具体策略——像中场球员，传递并处理
public class HighAmountStrategy implements RiskControlStrategy {
    private final RiskExternalService externalService;
    public boolean check(RiskContext ctx) {
        // 传球给外部服务（第二个配合点）
        boolean result = externalService.evaluate(ctx);
        // 接收返回值并加上自身判断（完成二过一射门）
        return result && ctx.getOrder().getAmount() < 50000;
    }
}
// 动态装配（教练的战术板）
public class StrategyFactory {
    public static RiskControlStrategy of(OrderType type) {
        if (type == VIP) return new HighAmountStrategy(new RiskExternalService());
        // 其他策略...
    }
}

为什么这算“二过一”？ 因为PaymentService（A）传球给Strategy（B），B又传给ExternalService（C），C返回结果，B再回传，整个过程没有直接让A去调用C，而是通过B这个中间人完成了“传球+跑位”的配合，这在代码里叫依赖倒置：高层的PaymentService不依赖具体的风控细节,只依赖抽象策略接口。

深度问答：为什么说好的架构像默契的传球？

问1：如果不用策略模式，直接用if-else不也能实现吗？ 答：能，但那是“个人英雄主义”，比如新加一套“大促风控规则”，你得改PaymentService这个类，这违反了开闭原则，而策略模式，你只需要新增一个PromotionStrategy类，像换人一样换上即可，其他代码不懂，这就像足球里，前锋A受伤了，教练直接从替补席叫个人上去,战术体系不变。

问2：这个案例中的“二过一”和Context参数传递有什么关系？ 答：Context是“球权”的载体，如果没有Context，A和B就得互相传几百个参数，像球场上一个球员带球单人突破，迟早被抢断，用Context统一封装变量，就是明确了传球路线——A只需要把整个球场状态交给B,B自己知道该看哪块区域。

问3：这个案例对学习设计模式有什么启发？ 答：别死背模式类图，你看这个案例，其实是策略模式+工厂模式+参数对象模式的混合体，真正的设计模式应用，是像足球教练一样根据场上情况（需求变更）动态调整阵型，当你能把Strategy想成“接应球员”，把Context想成“球”,写代码就有节奏感了。

实战启示：如何训练你的代码“团队意识”

搞清角色定位：在写合作类之前，问自己：“我是前锋（发起者），还是中场（策略），还是后卫（外部服务）？”明确职责,避免大而全的上帝类。
使用@FunctionalInterface：Java 8的Lambda让策略模式像场边换人牌一样轻量，例如上面的RiskControlStrategy，调用时直接(ctx) -> { return true; },不用新建类。
面向接口，而非实现：就像传球给“前锋”，而你并不需要知道他是梅西还是C罗，调用方只依赖RiskControlStrategy,管他内部是调用外部API还是本地规则。
警惕“过度配合”：如果策略只有两三个，没必要用工厂，就像小场足球，3个人的配合直接短传就行，非要叫个战术板反而拖延时间（代码冗余）。