适配器是外部 SOAP 客户端的正确模式吗？

如何解决适配器是外部 SOAP 客户端的正确模式吗？

我的软件是一个 Java EE 应用程序，它通过 SOAP 与另一个服务对话。我想创建一个更易于测试的层，并为此使用理想的解决方案。我不确定哪种模式适合这个问题。

我有一个名为 InputData 的内部数据类。它使用本地正确的数据类型。另一方面，SOAP 接口需要字符串中的大部分数据，例如“dd.MM.yyyy”中的日期，布尔值作为“0”和“1”以及其他一些奇怪的规则。我无法改变这一点。

所以我需要在这中间加一层。首先我认为最好的方法是使用纯函数，因为它们更容易测试而没有任何副作用。我的想法是创建一个带有静态方法的类，其中一个是公共的。我应该返回一个 ValueObject，它以正确的格式保存所有数据。

我找不到名字，所以我从“适配器”开始。但是有这样的事情：

public class SoapDataAdapter {
    public static SoapData getSoapData(InputData input) {
        SoapData data = new SoapData();

        data.setDate = getDate(input.getDate());
        data.isCustomer = isCustomer(input.isCustomer());
        // and many more

        return data;
    }

    private static String getDate(LocalDate date) {
        return DateHelper.toSoapDate(date);
    }

    private static String isCustomer(boolean isCustomer) {
        return isCustomer ? "0" : "1";
    }
}

但这不是根据已知模式的适配器。但它也不是工厂——如果我按照四人帮的定义——也不是。

然后我不确定如何称呼它，或者“真正的”适配器是否是更好的选择。所以我尝试了这个：

public class SoapDataAdapter {
    private InputData input;

    public SoapData getSoapData(InputData input) {
        this.input = input;
    }

    public String getDate() {
        return DateHelper.toSoapDate(input.getDate());
    }

    public String isCustomer() {
        return input.isCustomer ? "0" : "1";
    }
}

GoF 设计模式围绕 OOP 聚集，这可能并不总是最好的解决方案。拥有那些纯函数对我来说很有意义，而不是有创建实例和保持状态的开销。此外，我的目标是让它更容易理解和更容易测试。

1. 您认为该问题的最佳解决方案是什么？第一种、第二种甚至另一种解决方案？ （如果我理解正确的话，适配器似乎是适合该问题的模式。）
2. 你会怎么称呼第一个？这里的工厂可以接受吗？