消灭POJO样板与复杂分支：Java记录类+模式匹配双重实战

一个项目写久了，经常在几个看似不起眼的地方堆积出成片的垃圾代码。一个是层出不穷的DTO、VO、POJO，每个类都需要手写构造函数、getter、equals、hashCode、toString，偶尔漏改一个字段的equals就埋下诡异的bug。另一个是业务逻辑里的条件分支：if-else一层套一层，判断类型、判断状态、强制转型，读起来像是在解一团缠了半年的耳机线。

这种感觉在接手一个订单系统重构任务时达到了顶点。看着超过六十个字段的订单实体以及几百行的流程判断代码，我觉得是时候把Java 16的记录类和Java 17之后的模式匹配搬出来彻底整治一下了。改完后代码量少了一半，而且编译器还会在你漏写分支时主动报错，这种安全感让人踏实。这里就把重构的思路和关键代码完整复盘出来。

记录类：一刀斩断样板代码

记录类用起来像是专门为数据传输对象量身打造的关键字。以前创建一个不可变的数据载体，可能需要这样的代码：

public final class OrderItem {
    private final String productId;
    private final int quantity;
    
    public OrderItem(String productId, int quantity) {
        this.productId = productId;
        this.quantity = quantity;
    }
    public String getProductId() { return productId; }
    public int getQuantity()    { return quantity; }
    
    @Override
    public boolean equals(Object o) { /* 手工实现 */ }
    @Override
    public int hashCode() { /* 手工实现 */ }
    @Override
    public String toString() { /* 手工实现 */ }
}

仅是一个简单的类就膨胀到了三十多行，而且每次新增字段所有方法都得同步修改。用记录类重写之后：

public record OrderItem(String productId, int quantity) {}

一行搞定。编译器会自动生成规范的全参构造函数、字段访问方法（注意没有get前缀，直接是productId()和quantity()）、equals、hashCode和toString。而且记录类默认是不可变的，这完美契合了大部分DTO和VO的使用场景。

订单聚合头也可以嵌套使用记录类：

public record OrderHeader(
    String orderId,
    String customerId,
    List<OrderItem> items,
    OrderStatus status
) {}

其中OrderStatus我们定义了一个enum，后面会一起配合模式匹配进行分发。记录类的字段本身是透明的，但也可以定义紧凑构造函数进行参数校验：

public record OrderItem(String productId, int quantity) {
    public OrderItem {
        if (quantity <= 0) {
            throw new IllegalArgumentException("数量必须大于0");
        }
    }
}

这样一来，不安全的创建行为在入口就被拦截，后续代码可以完全信任数据的合法性。

模式匹配：让if-else和类型判断优雅退休

订单系统里常见一幕是根据订单的支付状态或物流状态走不同分支。之前写：

if (order instanceof PaidOrder) {
    PaidOrder paid = (PaidOrder) order;
    // 处理已支付
} else if (order instanceof CanceledOrder) {
    CanceledOrder canceled = (CanceledOrder) order;
    // 处理取消
} else {
    // ...
}

通过模式匹配，instanceof可以直接将值绑定到新变量：

if (order instanceof PaidOrder paid) {
    handlePayment(paid);
} else if (order instanceof CanceledOrder canceled) {
    handleCancel(canceled);
}

少了一行转型，但真正的飞跃发生在switch。Java 17起支持switch表达式对类型进行模式匹配，到Java 21更可以配合sealed类让编译器检查分支完整性。

我们把订单的几种变体定义成一个密封接口：

public sealed interface Order permits PaidOrder, CanceledOrder, RefundedOrder {
    String orderId();
}

具体实现：

public record PaidOrder(String orderId, PaymentInfo payment) implements Order {}
public record CanceledOrder(String orderId, String reason) implements Order {}
public record RefundedOrder(String orderId, BigDecimal refundAmount) implements Order {}

现在处理订单流程就可以写成这样：

public String processOrder(Order order) {
    return switch (order) {
        case PaidOrder paid -> "支付完成，金额：" + paid.payment().amount();
        case CanceledOrder canceled -> "已取消，原因：" + canceled.reason();
        case RefundedOrder refunded -> "已退款：" + refunded.refundAmount();
        // 如果缺少分支，编译器直接报错
    };
}

不用写default分支，因为sealed接口保证了这三种就是全部可能的类型。以后如果有人新增一种订单类型，所有这类switch都会被编译器标红提示，杜绝了漏改分支的线上事故。

实战：构建类型安全的订单处理流水线

实际项目中，订单不是孤零零的存在，往往需要配合库存、物流等多方服务。为此我们设计一套用记录类承载请求和响应，用模式匹配驱动流程的轻量结构。

首先定义几个核心记录类：

public record CreateOrderRequest(String customerId, List<OrderItem> items) {}
public record OrderResult(String orderId, Order order) {}
public record ErrorResult(String message) {}

然后编写处理器，不同订单类型走不同仓储逻辑：

public OrderResult handleCreate(CreateOrderRequest req) {
    // 校验与构建，略
    var order = new PaidOrder(generateId(), new PaymentInfo(BigDecimal.ZERO));
    return new OrderResult(order.orderId(), order);
}

public String processEvent(Order order) {
    return switch (order) {
        case PaidOrder p when p.payment().amount().compareTo(BigDecimal.ZERO) 
            "待支付订单";
        case PaidOrder p ->
            "已支付 " + p.payment().amount();
        case CanceledOrder c ->
            "取消原因：" + c.reason();
        case RefundedOrder r ->
            "退款金额：" + r.refundAmount();
    };
}

注意上面用到了守卫模式（when），可以在模式匹配的基础上附加布尔条件，进一步细化分支。这使得一些需要根据字段值细分的情况不必再退回if语句。

还可以在switch中解构嵌套的记录类，让代码更具表达力：

public record PaymentInfo(BigDecimal amount, PaymentMethod method) {}
public enum PaymentMethod { CREDIT_CARD, ALIPAY, WECHAT }

public String paymentDescription(Order order) {
    return switch (order) {
        case PaidOrder(var id, PaymentInfo(var amt, PaymentMethod.CREDIT_CARD)) ->
            "信用卡支付：" + amt;
        case PaidOrder(var id, PaymentInfo(var amt, var method)) ->
            "其他支付方式：" + method;
        default -> "非已支付状态";
    };
}

这种解构能力非常适合多层嵌套的数据模型，把原本需要层层getter的代码变为声明式的形状描述。

重构前后对比

重构之前，订单处理相关的类文件超过十五个，大量代码花费在getter/setter和条件分支的重复排列上。重构之后，所有DTO切换为记录类，平均每个类从三四十行缩减到一两行。条件逻辑迁移到增强型switch，配合sealed接口，分支覆盖率在一千米线代码里也能被编译器严格跟踪。结果不仅是代码量锐减，更重要的是认知负担大幅降低——新人读代码时不必在众多getter和if-else之间反复跳转，而是直接看到数据的结构以及针对每种情况如何响应。

使用时需要注意的一些边界

• 记录类不是JavaBean：它们没有默认构造器，字段没有setter方法，不适合那些需要框架填充属性的场景（比如很多ORM直接操作字段）。但在自行构建数据流时，不可变性反而是一个巨大的安全优势。
• 模式匹配不宜过深：嵌套解构让代码变简洁，但拆得太深容易让单个case变得脆弱。当数据层级超过两三层，考虑拆分为独立的处理函数。
• sealed接口要提前规划：如果你确定类型集合不会频繁扩展，sealed配合模式匹配是绝佳组合。但如果子类型经常变动，频繁维护sealed声明和所有switch分支也会成为负担。
• 升级门槛：模式匹配的持续增强（尤其是switch中的类型匹配）需要Java 17及以上，而记录类在Java 16即可使用。如果你的项目还在Java 11，需要评估升级成本，不过这些特性带来的长期维护收益往往值得一次JDK升级。

总结

记录类和模式匹配是两个互相成就的语言特性。前者把数据定义压到一行，后者让基于类型的逻辑派发变得安全而清晰。单独用每一个都能减少代码噪声，结合使用时会让整个数据流的处理变得像流水线一样直来直去。在经手过那个订单系统之后，我新建任何需要DTO和条件分发的模块，几乎不再写传统的类定义和if-else链。这种改变不是追求时髦，而是实实在在地让日常开发少了很多琐碎，多了很多确凿。