本文介绍如何避免冗长的 instanceof 判断，利用接口契约或 java 17+ 的 sealed class + switch 表达式，安全、可扩展地将多种业务对象统一映射为 timeintervalobj 列表。
本文介绍如何避免冗长的 instanceof 判断，利用接口契约或 java 17+ 的 sealed class + switch 表达式，安全、可扩展地将多种业务对象统一映射为 timeintervalobj 列表。
在实际开发中，我们常遇到多个结构相似但类型不同的领域对象（如 ObjectA、ObjectB、ObjectC），它们都包含语义相同的“起始时间”和“结束时间”字段。若为每种类型单独编写转换逻辑（如原代码中的多重 instanceof 分支），不仅重复冗余，更难以维护和扩展。理想方案应具备类型安全、开闭原则友好、零反射开销三大特性。
✅ 推荐方案一：统一接口抽象（兼容 Java 8+）
最简洁、普适性强的方式是定义公共接口，强制各目标类实现标准化的时间访问契约：
public interface TemporalEntity {
Timestamp getStartDate();
Timestamp getEndDate();
}让 ObjectA、ObjectB、ObjectC 均实现该接口：
@Data @AllArgsConstructor @NoArgsConstructor
public class ObjectA implements TemporalEntity {
private Timestamp startDate1;
private Timestamp endDate1;
@Override public Timestamp getStartDate() { return startDate1; }
@Override public Timestamp getEndDate() { return endDate1; }
}
// 同理实现 ObjectB、ObjectC（略）此时 TimeIntervalObj 的构造方法可彻底解耦：
public static List<TimeIntervalObj> constructTimeIntervals(List<?> source) {
return source.stream()
.filter(TemporalEntity.class::isInstance)
.map(TemporalEntity.class::cast)
.map(obj -> new TimeIntervalObj(obj.getStartDate(), obj.getEndDate()))
.collect(Collectors.toList());
}✅ 优势：无运行时类型检查异常风险；编译期强制约束；新增类型只需实现接口，无需修改转换逻辑。
✅ 推荐方案二：Sealed Class + Switch 表达式（Java 17+，推荐用于异构字段名场景）
当各对象的日期字段名不一致（如 startDate1 / startDate2 / startDate3）且无法统一命名时，接口抽象需配合 getter 重命名，略显牵强。此时可启用 Java 17 的 sealed 特性，结合 switch 模式匹配实现类型专属映射：
sealed interface TemporalEntity permits ObjectA, ObjectB, ObjectC {}各子类保持原有字段命名，并实现接口（仅作类型声明，无需 getter）：
@Data @AllArgsConstructor @NoArgsConstructor
final class ObjectA implements TemporalEntity {
Timestamp startDate1;
Timestamp endDate1;
}
// ObjectB、ObjectC 类似定义（字段名不同）定义类型感知的映射器：
private static TimeIntervalObj mapToInterval(TemporalEntity entity) {
return switch (entity) {
case ObjectA a -> new TimeIntervalObj(a.startDate1, a.endDate1);
case ObjectB b -> new TimeIntervalObj(b.startDate2, b.endDate2);
case ObjectC c -> new TimeIntervalObj(c.startDate3, c.endDate3);
};
}最终转换逻辑简洁清晰：
public static List<TimeIntervalObj> constructTimeIntervals(List<?> source) {
return source.stream()
.filter(TemporalEntity.class::isInstance)
.map(entity -> mapToInterval((TemporalEntity) entity))
.collect(Collectors.toList());
}⚠️ 注意：需启用预览特性（Java 17+ 编译时加 --enable-preview，运行时同理）；sealed 类型体系天然封闭，杜绝非法子类，提升可维护性。
? 不推荐做法及原因
- ❌ 使用 instanceof 多重判断 + 强制类型转换：违反开闭原则，新增类型需修改核心方法，易引入 ClassCastException。
- ❌ 依赖反射获取字段：性能损耗大、破坏封装、绕过编译检查。
- ❌ 泛型擦除后用 List
直接接收：无法在运行时识别具体类型，仍需类型判断。
总结
| 方案 | 兼容性 | 扩展性 | 类型安全 | 适用场景 |
|---|---|---|---|---|
| 统一接口 | Java 8+ | ★★★★★ | ★★★★★ | 字段语义一致、可约定 getter |
| Sealed + Switch | Java 17+（需 preview） | ★★★★☆ | ★★★★★ | 字段名/结构差异大，需精准分发 |
无论选择哪种方式，核心思想都是将类型差异收敛到契约或模式分支中，而非散落在流程控制里。这不仅提升了代码健壮性，也为未来引入策略模式、配置化映射等演进留出空间。
