使用适配器模式封装第三方类的java.util.Date？模式符合性与实现合理性问询

背景需求 #

需要在代码中隐藏旧的java.util.Date API，转而使用新的LocalDate。

相关代码 #

无法修改的旧类 #

// 无法修改该类
public class ProductExample {
  private Date createDate;

  private Integer id;

  public Date getCreateDate() {
    return createDate;
  }

  public Integer getId() {
    return id;
  }
}

适配器类 #

public class ProductExampleAdapter {

  private final ProductExample productExample;

  public ProductExampleAdapter(ProductExample productExample) {
    this.productExample = productExample;
  }

  public LocalDate getCreateDate() {
    return productExample.getCreateDate().toInstant()
            .atZone(ZoneId.systemDefault())
            .toLocalDate();
  }

  public Integer getId() {
    return productExample.getId();
  }
}

问题 #

请问这是否属于适配器模式？这是有效的使用场景吗？该实现是否良好？

回答 #

1. 这确实属于适配器模式 #

适配器模式的核心是将一个类的接口转换成客户端期望的另一个接口，让原本不兼容的接口可以协同工作。这里的ProductExampleAdapter通过组合旧的ProductExample对象，把返回Date的旧接口转换成了返回LocalDate的新接口，属于对象适配器的典型实现，完全符合适配器模式的定义。

2. 这是适配器模式的有效使用场景 #

当你无法修改遗留的ProductExample类（比如它是第三方库代码、或是已稳定的旧系统模块），但又想在新代码中统一使用Java 8+更安全、语义更清晰的日期API时，用适配器封装旧API的转换逻辑是非常合理的选择：

• 彻底隔离旧API对新代码的侵入，新代码无需直接处理Date类型
• 集中管理日期转换逻辑，避免重复代码散落在各处
• 符合“开闭原则”，无需修改原有类就能适配新的API需求

3. 实现整体良好，但有几个可优化的点 #

• 空值处理：当前代码未考虑productExample.getCreateDate()返回null的情况，运行时会抛出NullPointerException。建议添加空值判断，比如返回null或者抛出明确的业务异常
• 时区显式化：使用ZoneId.systemDefault()依赖系统本地时区，在分布式环境中可能导致日期转换结果不一致。如果业务有明确时区要求，建议替换为固定时区（比如ZoneId.of("Asia/Shanghai")），或者通过配置注入时区
• 接口抽象（可选）：如果后续有多个类似的旧类需要适配，可以定义一个统一的Product接口，让ProductExampleAdapter实现该接口，客户端面向接口编程，扩展性会更好

内容的提问来源于stack exchange，提问作者LagSurfer