我们应该有类似的DTO吗？

Question

我有2个dto，它们的用法不同，但是它们具有相似的字段。 例如， MyIdESDto使用信息从MyIdDto 。 后一个对象是用数据库中的数据构建的，而MyIdESDto是用MyIdDto构建的，并用MyIdDto数据完成的。

我认为应该只有1个DTO，并且该代码在DTO中设置了所需的任意多个字段。 其他人说MyIdESDto应该扩展MyIdDto。 其他人也同意这种实现方式，说如果删除某些功能，它不会破坏代码。 哪个更好用？ 能给我您选择的理由吗？

    @Data
    @NoArgsConstructor
    @JsonInclude(JsonInclude.Include.NON_NULL)
    public class MyIdESDto {
      private String name;
      private Integer id;
      private Integer age;


     public MyIdESDto(MyDto dto) {
        this.name = dto.getName();
        this.id = dto.getId();
        this.aage = 42;
     }
}




@Data
    @NoArgsConstructor
    @JsonInclude(JsonInclude.Include.NON_NULL)
    public class MyIdDto {
      private String name;
      private Integer id;
   }

Answer 1

由于第三组给出的相同原因，我将继续使用当前的实现。

对我而言，继承不是一个好主意，因为在这里我看不到is-a关系。 它们只是具有一些相似且有些相关的属性。

Answer 2

继承是表达A is-a B的手段 。 这并不意味着要防止代码重复。

所以，如果你能找到一个有意义的解释，为什么MyIdEDto 也是 MyIdDto -然后继承是天作之合。 如果不是，则留在两个不同的类中。

另一方面， 有时实用主义也能提供良好的指导。 因此，如果您的大多数团队都认为继承解决方案“更好”，那就去做吧。

换句话说：这确实是一个“样式”问题。 没有“更好”的选择，也没有硬道理可循。 因此：选择最适合负责代码的人员的解决方案。 分别针对受此决定影响最大的人（这两个群体并不总是相同的）。

Answer 3

DTO只是属性集（即没有业务逻辑）。 因此，通过引入DTO层次结构避免的唯一重复是setter和getter的重复，这可能会导致多行代码，但其本身并不复杂。

如果每个DTO建模不同的概念，并且两个类都不打算在相关代码中使用（可以从某种OO抽象中受益）， 则代码设置所需的字段数将使您难以跟踪已初始化的字段随时。 （例如，很明显， MyIdDto没有age ，但是如果我们使用MyIdESDto且age=0 ，我们将必须跟踪DTO的来源，以便知道我们是否可以信任的价值。 MyIdESDto.age ）。

面对此问题，我通常会考虑以下方式（我同意，可能会引起争议）：

在某些情况下，重复代码可以保持软件体系结构的清洁和易于理解。 重复项还可以用于防止难以理解的复杂抽象进入系统（...）。为解决两个或多个相似但单独发展的需求而被抽象的代码可能难以修改。

“克隆被认为是有害的”被认为是有害的：软件的克隆模式。