旧逻辑兼容整改之其他方案(分二)

VO 除【继承】、【复制全字段】之外的其他方案

前提：实体 ContNewCustomer extends ContCustomer，VO 层不想无脑继承，也不想复制一大堆字段。

方案 3：组合（聚合 / 委托），不继承，持有父 VO 对象

组合优于继承，经典设计模式思想。不写 extends，内部持有一个 ContCustomerVO customer;，需要什么就透传什么字段。

@Data
public class ContNewCustomerVO {
    // 组合，持有普通客户VO
    private ContCustomerVO customer;

    // 自己新增的独有字段
    private String inviteCode;
    private LocalDateTime registerTime;
}

✅优点

1. 没有继承的字段全部泄露问题；不想输出的字段直接不调用就行
2. 公共字段复用一份，不用复制粘贴
3. 父类新增字段，不会自动平铺到本 VO，不会意外泄露

❌缺点

1. JSON 输出是嵌套结构：{"customer":{"id":1,"name":"xx"},"inviteCode":"xxx"}，字段包一层 customer 对象。
2. 前端要改取值路径，customer.name，而不是直接 name。
3. Swagger 文档会出现嵌套对象。

如果前端不能接受嵌套对象，不适合这个原生写法。

进阶：组合 + @JsonUnwrapped 把嵌套打平输出

@JsonUnwrapped 序列化时把内部对象字段平铺到外层 JSON，对外表现和继承一模一样。

@Data
public class ContNewCustomerVO {
    @JsonUnwrapped
    private ContCustomerVO customer;

    private String inviteCode;
    private LocalDateTime registerTime;
}

输出 JSON：

{
  "id":1,
  "customerName":"xxx",
  "phone":"133...",
  "inviteCode":"A001"
}

⚠️坑点：

1. 反序列化有 bug，@JsonUnwrapped 入参接收的时候容易出问题，适合只做返回 VO，不要用作接收请求的入参 DTO。
2. 字段重名会冲突；
3. swagger3 对@JsonUnwrapped支持很差，文档不会自动展开，文档会显示嵌套对象。

方案 4：抽公共抽象 VO / 公共字段接口（接口抽取 getter）

把公共字段抽成接口，两个 VO 都实现接口，接口只定义 get/set 方法，不存字段。

适合多个 VO 都有同一批公共字段，但不想继承实体 VO。

public interface ICustomerCommon {
    Long getId();
    void setId(Long id);
    String getCustomerName();
    void setCustomerName(String customerName);
}

//普通客户VO
@Data
public class ContCustomerVO implements ICustomerCommon{
    private Long id;
    private String customerName;
    private String phone;
}

//新客户VO，实现接口，自己定义字段，不继承ContCustomerVO
@Data
public class ContNewCustomerVO implements ICustomerCommon{
    private Long id;
    private String customerName;
    private String inviteCode;
}

✅优点：面向接口编程，统一方法签名；适合工具统一处理公共字段。❌缺点：字段依然要复制，只是约束方法，减少写错字段名，没有省去属性定义。

方案 5：不维护两套 VO，使用 MapStruct 做转换（最推荐业务项目）

VO 类只写本接口真正需要输出的字段，不继承，不复制；实体类ContNewCustomer extends ContCustomer保留继承；通过 MapStruct 自动把实体的属性映射到 VO。

VO 就写自己接口需要的字段，要什么写什么，不用管实体继承关系。

//VO，只写接口要输出的字段，不继承
@Data
public class ContNewCustomerVO {
    private Long id;
    private String customerName;
    private String inviteCode;
    private LocalDateTime registerTime;
    //不需要phone，balance就不写
}

Mapper：

@Mapper(componentModel = "spring")
public interface CustomerMapper {
    ContNewCustomerVO toVo(ContNewCustomer entity);
}

✅优点

1. VO 完全是接口契约，干净，要什么写什么，不受实体继承干扰
2. 实体那边可以随便继承，VO 层完全隔离，实体改动不会影响 VO，除非你主动映射
3. 不需要复制粘贴字段，编译期生成转换代码
4. 可以灵活忽略字段、字段改名、格式化

❌缺点

引入 MapStruct 依赖；需要维护 mapper 接口；新增字段需要确认是否映射。

企业项目主流方案：实体随意继承，VO 不继承实体 / 父 VO，MapStruct 做转换。

方案 6：动态输出（Jackson 视图 @JsonView）

同一个 VO 类，定义不同视图，不同接口输出不同字段，不用新建多个 VO 类。

public class View {
    public interface Simple {}
    public interface Detail extends Simple {}
}

@Data
public class ContCustomerVO {
    @JsonView(View.Simple.class)
    private Long id;
    @JsonView(View.Simple.class)
    private String customerName;

    @JsonView(View.Detail.class)
    private String balance;
}

接口 1 返回简单客户（Simple 视图，不输出 balance）；接口 2 返回详情（Detail 视图输出全部）。

✅优点：少写 VO 类；同一个实体复用。❌缺点：

1. 多个接口共用一个 VO，视图多了之后维护灾难；
2. swagger 对 JsonView 支持差，文档不能区分不同视图的字段；
3. 阅读代码很难一眼看出来这个接口到底返回哪些字段。

小接口可以用，业务复杂不推荐。

全部方案汇总对比

表格

给你选型建议

1. 如果这个 VO同时作为入参和出参：不要用@JsonUnwrapped组合，坑很多。
2. 业务系统优先：实体继承保留，VO 不继承，MapStruct 映射，这是最稳的工程方案。
3. 简单小接口，字段几乎全部复用：直接 VO 继承。
4. 接口要裁剪大量字段：手写 VO 字段，或者 MapStruct。

避坑重点

实体类的继承是面向数据库、业务逻辑；VO/DTO 是面向接口契约，二者的继承关系尽量不要绑定在一起。