对象转换模式答案

【问题标题】：Object Conversion Pattern对象转换模式
【发布时间】：2010-11-17 05:23:30
【问题描述】：

我有几个来自外部来源（不可修改）的不同类，它们代表相同的概念。例如Address。我有com.namespace1.Address（带有字段houseNum、street、city）、com.namespace2.Address（带有字段h、s、c）、namespace3.com.CoolAddress（带有字段@9876543 street，city)。

问题是我使用的某些 Web 服务需要某些地址对象类型，因此我需要在给定 namespace3.com.CoolAddress 的情况下创建一个 com.namespace1.Address。这些字段很容易映射，但我正在寻找如何做到这一点的模式。

在我看来，实例对象AddressConverter 没有意义，因为没有状态（只有行为），当类只有行为时，它归结为实用程序类中的静态方法。从长远来看，每当我需要将新对象相互映射时，我都有一个地方可以添加/修改/删除方法。它的完成方式可能会改变，但我知道代码所在的位置（在一次位置），并且可以在需要时更改映射。

想法？

【问题讨论】：

标签： java object dictionary design-patterns

【解决方案1】：

你需要输出final的类吗？如果没有，您可以将它们子类化以创建正确的Adapters。否则我会接受 dj_segfault 的建议，即带有处理程序表的工厂。

或者，等等——它只是你需要与之交谈的网络服务吗？如果是这样，那么您的数据类型的实现应该没有理由不能是包装输入数据类型的适配器或您自己的一些中间对象。

【讨论】：

【解决方案2】：

如果您总是转换到同一个类，我会保持简单，并将所有转换代码放在该类中，而不用担心工厂等，尤其是当您只处理几个不同的类时。为什么这些东西总要有一个复杂的模式？！

public class A {

    ...

    public static A convertB(B b) {

    ...

    }
}

【讨论】：

问题说原始对象是不可修改的。
@BrianYarger 我认为他的意思是类定义是不可修改的。我基于以下句子：“在给定 namespace3.com.CoolAddress 的情况下，我需要创建 com.namespace1.Address”。
通过将转换逻辑放在类中，代码现在是紧密耦合的。设计模式的一个要点是避免可以相互独立存在的类的耦合。我会反对这个答案中的建议。

【解决方案3】：

由于您不能自己修改类，我建议为每个方向实现Adapter 模式。正如您所说，适配器方法本身可以是静态的，但是您可以将两个方向组合在一个类中，以便逻辑都在一个地方。

在一天结束时，无论您如何称呼它或将代码放在哪里，您都将执行相同的任务。我建议将两个方向放在同一个文件中，因为当任一方向发生变化时，它们通常都需要更新。

【讨论】：

【解决方案4】：

我认为您正在寻找的是一个工厂类。当您需要能够实例化几个相关类之一时使用工厂模式，由工厂而不是开发人员决定。

见http://en.wikipedia.org/wiki/Factory_method_pattern

您尝试将所有这些业务逻辑保存在一个地方而不是 ClassOne.toClassTwo()、ClassOne.toClassThree()、...

是对的

我能想到的最灵活的实现方式（但目前还不是最简单的）是让工厂从一个只有基本常用方法的简单类开始，然后将处理程序添加到 Hashtable 或其他容器中。这样您就不需要对每种可能的功能组合进行具体实现。

当然，为每个可能的地址变体都有一个具体的实现会更快，但是会有相当多的重复代码，并且添加新的地址类类型会有点困难。

【讨论】：

+1 表示处理程序表建议——我经常使用这种模式。但是使用Map 而不是Hashtable。 :)
工厂是一种创造模式。问题在于管理现有对象而不是创建新对象。
@icepack 我认为 OP 确实希望在将一个对象映射到另一个对象时创建新实例。我认为“来自外部来源的几个不同的对象（不可修改）”这句话意味着对象的类是不可修改的。我基于以下句子：“在给定 namespace3.com.CoolAddress 的情况下，我需要创建 com.namespace1.Address。”。我将编辑句子。