在一个综合电商系统中，订单可能来自实物商品、虚拟课程、酒店预订等不同业务线。每种订单除了订单号、金额、创建时间等公共字段外，还携带完全不同的条件属性：实物订单需要收货地址和物流单号，课程订单需要学员姓名和有效期，酒店订单需要入住日期和房间数。如果把这些属性全部堆在一个Order类里，再加上一个type枚举区分订单类型，代码会迅速膨胀。
更麻烦的是，这种设计并非只是字段多少的问题，它会把业务规则分散到大量if-else分支中，同时让空指针异常成为常态。本文将介绍一种更优雅的建模方式：先用继承拆分条件属性，再用泛型基类保留类型安全，从而绕开枚举方案常见的陷阱。
一、枚举方案为什么容易变成陷阱
很多团队最初为了快速上线，会创建一个统一的Order实体，把实物订单、课程订单、酒店订单等所有可能用到的属性都放进去，再用一个OrderType枚举来标识当前订单属于哪种类型。典型代码如下：
public enum OrderType {
PHYSICAL, COURSE, HOTEL
}
public class Order {
private String orderNo;
private BigDecimal amount;
private OrderType type;
private String address;
private String logisticsNo;
private String studentName;
private LocalDate validUntil;
private LocalDate checkInDate;
private Integer roomCount;
// 省略getter和setter
}
这种设计在初期确实简单，因为所有数据都在一个类里，读写方便。但随着业务增长，问题会逐渐暴露。当业务方调用getStudentName()时，如果当前订单是酒店类型，返回值是null，但编译器不会给出任何提示。所有字段都集中在同一个类里，阅读代码的人无法判断哪些字段属于哪个业务场景。更糟的是，业务逻辑会充满大量if-else分支：
public void process(Order order) {
if (order.getType() == OrderType.PHYSICAL) {
// 处理收货地址和物流
} else if (order.getType() == OrderType.COURSE) {
// 处理学员和有效期
} else if (order.getType() == OrderType.HOTEL) {
// 处理入住和房间数
}
}
新增一种订单类型时，需要修改实体类增加字段，还要在所有涉及类型判断的地方补分支，系统扩展成本越来越高。枚举本身还容易在序列化、日志输出和接口文档中暴露过多的内部状态，一旦重命名字段值，旧数据就可能反序列化失败。
二、继承拆分条件属性：多态替代分支
更自然的建模方式是把订单设计成抽象基类，让每个具体业务类型拥有自己的类。基类只保留公共字段，差异属性下沉到子类。这样每个子类的职责非常清晰，外部拿到子类对象时也能明确知道它具备哪些属性。
public abstract class Order {
private String orderNo;
private BigDecimal amount;
private LocalDateTime createdAt;
// 省略getter和setter
}
public class PhysicalOrder extends Order {
private String address;
private String logisticsNo;
// 省略getter和setter
}
public class CourseOrder extends Order {
private String studentName;
private LocalDate validUntil;
// 省略getter和setter
}
public class HotelOrder extends Order {
private LocalDate checkInDate;
private Integer roomCount;
// 省略getter和setter
}
这样设计后，PhysicalOrder只包含地址和物流单号，HotelOrder只包含入住日期和房间数。业务代码不再依赖一个庞大的枚举，而是通过instanceof或方法重载来针对具体类型处理。例如发货操作只接收实物订单：
public void ship(PhysicalOrder order) {
String address = order.getAddress();
String logisticsNo = order.getLogisticsNo();
// 执行发货逻辑
}
与枚举加可空字段相比，这个模型有明确的边界：当你拿到一个PhysicalOrder对象时，编译器知道它一定有地址信息；当你需要处理发货逻辑时，可以单独编写接收PhysicalOrder参数的方法。新增订单类型只需要新建子类，不需要动已有的Order基类和现有子类，符合开闭原则。
当然，instanceof不是唯一选择。也可以使用访问者模式或策略模式，让订单子类自己完成特定操作。不过对大多数业务系统来说，先建立清晰的继承层次已经能解决大部分可读性和维护性问题。
三、泛型基类带来的类型安全与复用
继承解决了字段归属问题，但如果每个子类都需要重复定义一些和条件属性相关的访问逻辑，仍然会有冗余。比如基类想提供一个统一的详情对象，但不同订单详情类型不同，这时可以让基类携带泛型参数。
public interface OrderDetail {
}
public class PhysicalDetail implements OrderDetail {
private String address;
private String logisticsNo;
// 省略getter和setter
}
public class CourseDetail implements OrderDetail {
private String studentName;
private LocalDate validUntil;
// 省略getter和setter
}
public abstract class Order<D extends OrderDetail> {
private String orderNo;
private BigDecimal amount;
private D detail;
public D getDetail() {
return detail;
}
public void setDetail(D detail) {
if (detail == null) {
throw new IllegalArgumentException("订单详情不能为空");
}
this.detail = detail;
}
}
public class PhysicalOrder extends Order<PhysicalDetail> {
}
public class CourseOrder extends Order<CourseDetail> {
}
在这个设计中，PhysicalOrder继承Order<PhysicalDetail>，因此调用getDetail()时返回的直接是PhysicalDetail类型，不需要显式强转。编译器可以在编写阶段发现类型错误，例如把课程详情赋值给实物订单的detail字段会直接编译失败。
泛型基类还能让公共方法复用。你可以在基类中实现与detail相关的通用逻辑，比如非空校验、日志脱敏、变更追踪等，这些方法返回泛型类型，子类无需重写。这样既保留了继承带来的多态能力，又减少了重复代码。
注意Java泛型在运行时会被擦除，Order<PhysicalDetail>和Order<CourseDetail>在字节码层面都是Order，因此不要在基类中通过getClass()判断泛型实参。真正需要区分具体类型时，仍然应该使用继承后的类，或者显式传递Class<D>对象。
四、配合ORM与JSON序列化
使用继承后，持久化框架需要知道子类如何映射到数据库表。JPA提供三种策略：单表继承、联合继承和每类一表。单表继承把所有子类字段放在一张表中，通过标识列区分；联合继承把公共字段放在父表，子表只保存差异字段；每类一表则每个具体类生成独立表。可以根据查询模式和字段差异程度选择。
如果使用Jackson进行JSON序列化，建议在基类上添加多态注解，明确类型标识和子类映射。这样反序列化时可以根据type字段自动创建对应的子类实例。
@JsonTypeInfo(use = JsonTypeInfo.Id.NAME, property = "type")
@JsonSubTypes({
@JsonSubTypes.Type(value = PhysicalOrder.class, name = "PHYSICAL"),
@JsonSubTypes.Type(value = CourseOrder.class, name = "COURSE"),
@JsonSubTypes.Type(value = HotelOrder.class, name = "HOTEL")
})
public abstract class Order {
private String orderNo;
private BigDecimal amount;
// 省略公共字段
}
相比之下，原本的枚举字段虽然也能作为类型标识，但无法让JSON库自动选择实体类。你仍然需要先反序列化成统一实体，再根据枚举手动转换，多了一步容易出错的转换。使用多态注解后，接口输入输出直接对应具体的子类对象，代码更简洁，也避免了枚举值变更带来的兼容性问题。
五、实践建议与边界
这套继承加泛型的模型适合条件属性差异较大、类型相对稳定的业务场景，例如订单、工单、审批流程等。如果条件属性非常少或变化频繁，使用一个Map<String,Object>或JSON字段反而更灵活，不应为了设计而设计。建模前要先判断公共字段和差异字段的边界，公共字段应该是真正所有子类型共有的，例如主键、创建时间、状态等。若某个字段只在部分子类中出现，就应下沉到对应子类或详情对象中。
还要注意避免在基类中放置过多公共字段，否则又会回到大而全的实体。子类的差异属性最好通过详情对象或独立子类字段表达，保持每个类的字段数量相对均衡。当子类数量过多时，可以引入工厂模式统一创建对象，避免客户端直接依赖所有子类构造器。
最后，泛型与继承结合时需要注意泛型擦除限制，不要尝试在构造器或静态方法中直接创建泛型实例，也不要依赖instanceof判断泛型类型。如果确实需要运行期类型信息，可以将Class<D>作为参数传入，或者使用反射工具获取父类的泛型实参。这样可以避免一些隐蔽的运行时异常，让条件属性模型在长期维护中保持稳定。