Java常用设计模式与优雅接口实践：从一次批量发放接口接入说起

一、场景引入：一个batchSend方法背后的设计问题

在实际业务系统中，经常存在这样的需求：平台需要向一批用户批量发放权益，权益形态包括优惠券、返现卡、赠品卡等。为了统一入口，团队通常会抽象出一个批量发放接口，暴露一个核心方法：

public interface BenefitSender {
    BatchResult batchSend(BatchRequest request);
}

当新业务方需要把刚实现的赠品卡接入这套体系时，最直接的做法是写一个实现类，把赠品卡的发放逻辑塞进batchSend里。但代码 review 时往往能发现两个值得深究的现象：

第一，有人把这个实现类下沉到了common包，理由是他认为这个类”具备通用性”；
第二，这个类的写法借鉴了ORM框架中常见的链式构建风格，虽然一时说不清它属于哪种设计模式，但用起来确实顺手。

更值得注意的是，这个类在终止语义上做了区分：分别调用finished()和interrupted()，后续可执行的操作并不相同。例如调用interrupted()之后，还可以追加失败原因，再调用result设置最终结果。

这几个细节看似零散，实际上分别对应了模板方法、建造者、策略/工厂以及状态控制等几类经典设计模式的应用。本文就以这个场景为线索，系统梳理Java中比较常用的设计模式，以及它们在”写一套漂亮代码”这件事上的具体价值。

二、为什么接口设计需要设计模式

很多开发者对设计模式的理解停留在”面试八股”层面，认为它是为了炫技。但在真实工程里，设计模式解决的是三类反复出现的问题：

1. 变化点隔离：业务规则经常变，但调用方不应随之频繁改动；
2. 流程复用：多个实现共享同一套骨架流程，只在关键步骤上差异化；
3. 调用可读性：复杂对象的构造、多步骤操作的编排，需要让调用方一眼看懂意图。

批量发放接口恰好三者兼具：权益类型在变（优惠券、返现卡、赠品卡），发放流程高度相似（校验、组装、发送、记录结果），而请求参数和结果对象又相对复杂。下面逐一展开。

三、模板方法模式：把流程骨架固定下来

批量发放的通用流程大体一致：

1. 参数校验与用户去重；
2. 权益可用性检查；
3. 分批调用下游发放能力；
4. 汇总成功与失败明细；
5. 记录日志与结果回传。

如果每个权益实现类都把这些步骤重写一遍，既冗余又容易出错。模板方法模式的做法是：在抽象基类中定义batchSend的固定流程，把每一步拆成可覆写的方法。

public abstract class AbstractBenefitSender implements BenefitSender {
    @Override
    public final BatchResult batchSend(BatchRequest request) {
        validate(request);
        List<User> users = distinct(request.getUserIds());
        List<SendItem> items = prepare(users, request);
        BatchResult result = doSend(items);
        afterSend(result);
        return result;
    }
    protected void validate(BatchRequest request) { /* 通用校验 */ }
    protected List<SendItem> prepare(List<User> users, BatchRequest request) { /* 通用组装 */ }
    protected abstract BatchResult doSend(List<SendItem> items);
    protected void afterSend(BatchResult result) { /* 通用后置处理 */ }
}

这样做的收益很明确：新增一种权益，只需继承基类并实现doSend，流程骨架与通用校验、去重、日志全部复用。final修饰模板方法可以防止子类破坏流程顺序，这是模板方法模式的关键约束。

需要注意的是，抽象方法应尽量少，钩子方法（有默认空实现的方法）应尽量多，否则子类会被迫实现大量无关逻辑，反而降低扩展性。

四、建造者模式：让复杂请求的构造可读

批量发放的请求对象往往字段很多：用户列表、权益类型、权益模板、有效期、发放批次号、幂等键、扩展参数等。如果使用全参构造函数，调用处会出现一长串含义不明的参数；如果使用setter逐个设置，又容易出现漏设、顺序混乱。

建造者模式通过链式调用解决这个问题：

BatchRequest request = BatchRequest.builder()
        .userIds(userIds)
        .benefitType(BenefitType.GIFT_CARD)
        .templateId("tpl_1001")
        .expireAt(expireAt)
        .idempotentKey(bizNo)
        .build();

链式写法的本质是：每个设置方法返回this（建造者自身），最后由build()完成校验并产出不可变对象。相比setter，它有三个好处：

• 可读性：字段名紧跟赋值，语义清晰；
• 不可变性：构建完成后对象不再暴露修改入口，天然线程安全；
• 校验集中：必填项、互斥项检查可以统一放在build()里，避免非法对象流入下游。

这也解释了为什么”和ORM框架类似的写法”用起来顺手——它并不是某种神秘设计，而是建造者模式在参数对象上的标准应用。

五、策略模式与工厂模式：按权益类型分发

当权益类型不断增多时，if-else或switch会迅速膨胀。策略模式把每种权益的发放逻辑封装成独立实现，由工厂根据类型选择具体策略。

public interface BenefitSender {
    BenefitType type();
    BatchResult batchSend(BatchRequest request);
}
@Component
public class BenefitSenderFactory {
    private final Map<BenefitType, BenefitSender> registry = new HashMap<>();
    public BenefitSenderFactory(List<BenefitSender> senders) {
        senders.forEach(s -> registry.put(s.type(), s));
    }
    public BenefitSender get(BenefitType type) {
        BenefitSender sender = registry.get(type);
        if (sender == null) {
            throw new IllegalArgumentException("unsupported benefit type: " + type);
        }
        return sender;
    }
}

工厂在启动时把所有实现注册进Map，调用方按类型取用。这样新增权益类型只需新增一个实现类，符合开闭原则，也便于做灰度与降级（例如对某类型单独配置开关）。

六、分阶段状态控制：finished与interrupted的差异

原始场景中最值得玩味的一点，是finished()与interrupted()的语义区分。

• finished()表示流程正常结束：所有该发的东西都发完了，结果已确定，此时不应再追加失败原因，也不应再修改结果；
• interrupted()表示流程被中途打断：可能是下游超时、部分用户失败、或外部主动中止。此时允许追加失败原因、补充明细，再调用result生成最终结果。

这种设计本质上是一种轻量状态机：通过方法调用顺序约束对象状态，防止出现”已完成后又追加失败信息”这类非法状态组合。实现上可以用一个状态枚举加断言：

public class SendContext {
    private State state = State.RUNNING;
    private final List<FailureReason> failures = new ArrayList<>();
    public SendContext interrupted() {
        assertState(State.RUNNING);
        this.state = State.INTERRUPTED;
        return this;
    }
    public SendContext failReason(FailureReason reason) {
        assertState(State.RUNNING, State.INTERRUPTED);
        failures.add(reason);
        return this;
    }
    public BatchResult result() {
        assertState(State.RUNNING, State.INTERRUPTED, State.FINISHED);
        this.state = State.FINISHED;
        return new BatchResult(failures);
    }
}

配合链式返回this，调用方可以写出context.interrupted().failReason(r).result()这样的连贯表达，既保证语义正确，又保持可读性。这实际上是建造者模式与状态约束的结合用法，也是”漂亮代码”的一个典型特征：用类型和调用顺序表达业务约束，而不是靠注释提醒。

七、关于”下沉到common包”的判断

把实现类放进common包，出发点是”通用性”，但这里需要谨慎。common包通常被多个业务模块依赖，一旦放入带有具体业务语义的类，容易造成：

• 依赖倒置：底层公共包反向依赖具体业务概念；
• 变更扩散：common包改动影响面大，发布节奏受制；
• 职责模糊：通用能力与业务实现混在一起，后续难以界定边界。

更合理的做法是：接口与抽象基类放common，具体权益实现放各自业务模块，通过工厂在运行时装配。通用性应体现在抽象层，而不是把所有实现都塞进公共包。

八、小结

回到最初的问题——Java写一套漂亮的代码，哪些设计模式比较常用？结合这个批量发放接口的案例，可以给出一个务实的答案：

模式	解决的问题	典型落点
模板方法	固定流程骨架，隔离步骤差异	抽象发放基类
建造者	复杂对象构造可读、可校验	请求/结果对象
策略 + 工厂	按类型分发，消除条件分支	权益发送器注册表
状态约束	约束调用顺序，防止非法状态	上下文的finished/interrupted

设计模式的价值不在于名字，而在于它把”变化”关进了确定的笼子里：流程稳定、扩展点清晰、调用方语义明确。能做到这三点，代码自然就漂亮了。