Java代码优雅重构：多态与设计模式实战解析

在Java业务开发中，随着系统迭代，代码往往容易演变成充斥着if-else分支的“屎山”。当面对新增需求时，许多开发者的第一反应是在原有方法中追加条件判断。然而，真正优雅的代码应当在扩展时无需修改原有核心逻辑。本文将结合一个批量权益发放的实际场景，深入探讨如何运用面向对象的多态特性及经典设计模式，重构并编写出具备高扩展性的漂亮代码。

一、场景还原：一次避开“if-else”陷阱的迭代

假设我们接手了一个权益发放的微服务接口，该接口负责向用户批量发放各类权益，如优惠券、返现卡等。当前的需求是新增一种“赠品卡”的发放逻辑。

如果按照过程式的编程思维，代码极有可能长这样：

public void batchSend(String type, List<User> users) {
    if ("Coupon".equals(type)) {
        // 发放优惠券逻辑
    } else if ("Cashback".equals(type)) {
        // 发放返现卡逻辑
    } else if ("GiftCard".equals(type)) {
        // 新增赠品卡逻辑
    }
    // 后续无尽的 else if...
}

这种写法看似直接，实则隐患重重：每新增一种权益类型，都需要修改核心业务类，违反了开闭原则（OCP）；且随着分支增多，方法体急剧膨胀，测试和维护成本呈指数级上升。而在实际接触到的优秀代码中，核心入口往往没有哪怕一个if-else，这背后依托的正是多态与设计模式的巧妙结合。

二、多态与模板方法模式：抽离共性，隔离变化

在没有if-else的架构中，寻找对应权益的实现逻辑通常依赖于继承体系与多态机制。

1. 继承体系的建立

首先，定义一个统一的接口，例如RightsSendRpc，声明批量发放的方法。然而，如果让每种权益的子类直接实现该接口，会导致通用的记录操作在各个子类中重复编写。

2. 模板方法模式的引入

为了复用代码，引入模板方法模式。定义一个抽象类AbstractRightsSendHandler，它实现了RightsSendRpc接口，并将通用的逻辑固定下来。例如，在批量发放过程中，无论是哪种权益，都需要记录操作流水表record和明细表recordDetail，以便在部分失败时进行重试。

抽象类中的batchSend方法定义了算法骨架：

public abstract class AbstractRightsSendHandler implements RightsSendRpc {
    // 模板方法，定义为final，防止子类修改核心流程
    @Override
    public final void batchSend(List<User> users) {
        // 1. 前置通用操作：记录主任务流水
        saveRecord(users);
        // 2. 交给具体子类实现的发送逻辑
        boolean isSuccess = send(users);
        // 3. 后置通用操作：记录明细及状态
        saveRecordDetail(isSuccess);
    }
    // 抽象方法，由子类实现具体的权益发放
    protected abstract boolean send(List<User> users);
    private void saveRecord(List<User> users) { /* 通用记录逻辑 */ }
    private void saveRecordDetail(boolean isSuccess) { /* 通用明细逻辑 */ }
}

通过这种设计，通用的记录操作被下沉到抽象类中，子类（如CouponSendHandler、GiftCardSendHandler）只需关注自身的send方法。新增赠品卡时，只需新建一个子类即可，核心类无需任何修改。

三、向下封装：下沉common包的设计哲学

在审查代码结构时，如果发现开发者将抽象类及相关组件下沉到了common包中，这通常意味着该开发者具备良好的全局视野。

将抽象类放置于common或core包，表明这套基于模板方法的处理框架具备通用性。它不再局限于当前的权益发放业务，甚至可以推广到消息批量推送、积分批量结算等类似“批量执行 + 记录状态”的场景中。这种高度抽象的包结构划分，使得基础设施与业务逻辑解耦，其他业务线在迭代时也能直接复用这套底座。

四、建造者模式与状态闭环：打造优雅的执行结果

在复杂的批量操作中，如何优雅地处理和返回执行结果是一大挑战。部分成功、部分失败、中断等状态需要被精准表达。此时，可以借鉴建造者模式的思想，构建一个BatchResult对象。

1. 流式API的设计

通过类 builder 模式，开发者可以像使用某些业界知名的ORM框架一样，以流式调用的方式组装结果，极大提升了代码的可读性：

BatchResult result = new BatchResult.Builder()
    .total(users.size())
    .successCount(successList.size())
    .build();

2. 状态驱动的后续操作

更高级的设计在于，BatchResult能够根据不同的终止状态提供不同的后续处理能力。当批量操作正常完成时，调用finished()方法；当遇到异常中断时，调用interrupted()方法。

这种设计的精妙之处在于状态与行为的绑定：

// 正常完成场景
BatchResult result = BatchResult.finished().result(successList);
// 异常中断场景
BatchResult result = BatchResult.interrupted()
    .appendFailReason("第三方接口超时") // 追加失败原因
    .result(partialSuccessList);      // 设置已处理的部分结果

通过interrupted()进入中断状态后，对象内部允许调用appendFailReason等专属方法来收集诊断信息；而通过finished()进入完成状态时，则不允许追加失败原因。这种状态保护机制有效防止了非法的状态变更，保障了数据的严谨性。

五、总结与最佳实践

编写一套漂亮的Java代码，绝非堆砌奇技淫巧，而是对设计原则的深刻理解与恰当应用：

1. 消灭if-else靠多态：利用面向对象的多态特性，结合工厂模式或路由表，将分支逻辑转化为动态绑定。
2. 复用逻辑靠模板：通过模板方法模式，在抽象父类中固化算法骨架，提取公共操作（如日志、记录、鉴权），子类只实现差异化逻辑。
3. 结果处理靠封装：引入建造者模式或状态模式封装复杂的执行结果，提供流式API提升编码体验，同时通过状态校验确保业务数据的闭环与严谨。

在日复一日的开发中，当我们面对“在原有代码上增加迭代”的需求时，不应仅仅满足于“实现功能”，而应思考当前的代码结构是否支持平滑扩展。通过对通用逻辑的下沉与设计模式的合理引入，我们完全可以写出兼具优雅与健壮性的工程级代码。