如何使参数保持低计数并仍保持第三方依存关系独立？

我使用第三方图书馆。他们向我传递了一个POJO，出于我们的意图和目的，可能是这样实现的：

public class OurData {
  private String foo;
  private String bar;
  private String baz;
  private String quux;
  // A lot more than this

  // IMPORTANT: NOTE THAT THIS IS A PACKAGE PRIVATE CONSTRUCTOR
  OurData(/* I don't know what they do */) {
    // some stuff
  }

  public String getFoo() {
    return foo;
  }

  // etc.
}

由于很多原因，包括但不限于封装他们的API和促进单元测试，我想包装他们的数据。但是我不希望核心类依赖于它们的数据（再次出于测试原因）！所以现在我有这样的事情：

public class DataTypeOne implements DataInterface {
  private String foo;
  private int bar;
  private double baz;

  public DataTypeOne(String foo, int bar, double baz) {
    this.foo = foo;
    this.bar = bar;
    this.baz = baz;
  }
}

public class DataTypeTwo implements DataInterface {
  private String foo;
  private int bar;
  private double baz;

  public DataTypeOne(String foo, int bar, double baz, String quux) {
    this.foo = foo;
    this.bar = bar;
    this.baz = baz;
    this.quux = quux;
  }
}

然后这个：

public class ThirdPartyAdapter {
  public static makeMyData(OurData data) {
    if(data.getQuux() == null) {
      return new DataTypeOne(
        data.getFoo(),
        Integer.parseInt(data.getBar()),
        Double.parseDouble(data.getBaz()),
      );
    } else {
      return new DataTypeTwo(
        data.getFoo(),
        Integer.parseInt(data.getBar()),
        Double.parseDouble(data.getBaz()),
        data.getQuux();
      );
  }
}

该适配器类与其他一些必须了解的第三方API结合在一起，从而限制了它在我系统的其余部分中的普遍性。但是...这个解决方案很重要！在第40页的清理代码中：

超过三个论点（多元论）需要非常特殊的理由-因此无论如何都不应使用。

我考虑过的事情：

• 创建工厂对象而不是静态辅助方法
  • 不能解决拥有数十亿论点的问题
• 创建具有依赖构造函数的DataTypeOne和DataTypeTwo的子类
  • 仍然具有受多态保护的构造函数
• 创建完全相同的接口的完全独立的实现
• 多个上述想法同时

这种情况应该如何处理？

请注意，这不是反腐败层的情况。他们的API没有错。问题是：

• 我不希望我的数据结构具有 import com.third.party.library.SomeDataStructure;
• 我无法在测试用例中构造它们的数据结构
• 我当前的解决方案导致非常高的参数计数。我想保持参数计数低，而无需传递其数据结构。
• 这个问题是“ 什么是反腐败层？”。我的问题是“ 如何使用一种模式（任何模式）来解决这种情况？”

我也不要求代码（否则这个问题将在SO上），只是要求足够的答案以使我能够有效地编写代码（该问题未提供）。

当有多个初始化参数时，我使用的策略是创建一个仅包含初始化参数的类型

public class DataTypeTwoParameters {
    public String foo;  // use getters/setters instead if it's appropriate
    public int bar;
    public double baz;
    public String quuz;
}

然后，DataTypeTwo的构造函数接受一个DataTypeTwoParameters对象，并通过以下方式构造DataTypeTwo：

DataTypeTwoParameters p = new DataTypeTwoParameters();
p.foo = "Hello";
p.bar = 4;
p.baz = 3;
p.quuz = "World";

DataTypeTwo dtt = new DataTypeTwo(p);

这给了很多机会来弄清楚进入DataTypeTwo的所有参数是什么以及它们的含义。您还可以在DataTypeTwoParameters构造函数中提供合理的默认值，以便仅以API使用者喜欢的任何顺序完成需要设置的值。

在这里，您确实有两个单独的问题：包装API和使参数计数保持较低。

包装API时，其想法是像从头开始一样设计接口，除了要求外，一无所知。您说他们的API没什么问题，然后在同一个清单中列出了他们的API的许多问题：可测试性，可构造性，一个对象中的参数太多，等等。编写您希望拥有的API 。如果那需要多个对象而不是一个，请执行此操作。如果需要将上一层包装到创建 POJO 的对象上，请执行此操作。

然后，有了所需的API后，参数计数可能不再是问题。如果是这样，则可以考虑以下几种常见模式：

• 参数对象，如Erik的answer所示。
• 该生成器模式，让您创建一个单独的生成器对象，然后调用一些制定者的单独设定参数，然后创建你的最终目标。
• 该原型模式，在那里你克隆你想要的对象的子类与领域已经内部设置。
• 您已经熟悉的工厂。
• 以上几种组合。

请注意，这些创建模式通常最终会调用一个polyadic构造函数，将其封装后，您应该认为还可以。多元构造函数的问题不是一次调用它们，而是在您每次需要构造一个对象时都被迫调用它们的时候。

请注意，通过存储对OurData对象的引用并转发方法调用，而不是尝试重新实现其内部结构，通常可以更轻松，更易于维护地传递给底层API 。例如：

public class DataTypeTwo implements DataInterface {
  private OurData data;

  public DataTypeOne(OurData data) {
    this.data = data;
  }

   public String getFoo() {
    return data.getFoo();
  }

  public int getBar() {
    return Integer.parseInt(data.getBar());
  }
  ...
}

我认为您可能对鲍伯叔叔的建议过于严格地解释了。对于具有逻辑，方法和构造函数等的普通类，多元构造函数确实确实感觉很像代码气味。但是对于严格来说是公开字段的数据容器并且已经由本质上已经由Factory对象生成的东西而言，我认为它并不算太糟糕。

您可以使用Parameter Object模式，如注释中所建议的那样，可以为您包装这些构造函数参数，您的本地数据类型包装器实际上已经是Parameter对象。您所有Parameter对象要做的就是打包参数（如何创建参数？如何使用polyadic构造函数？），然后稍后再将其打包到几乎相同的对象中。

如果您不想公开您的字段的setter并调用它们，我认为坚持在定义明确且封装好的工厂中使用polyadic构造函数是可以的。