java 对象转换模式

Object Conversion Pattern

提问by djunforgetable

I have several different classes coming from external sources (unmodifiable) that represent the same concept. For example Address. I have com.namespace1.Address(with fields houseNum, street, city), com.namespace2.Address(with fields h, s, c), namespace3.com.CoolAddress(with fields house_num, street, city).

我有几个来自外部来源（不可修改）的不同类，它们代表相同的概念。例如Address。我有com.namespace1.Address（有田houseNum，street，city）， com.namespace2.Address（与领域h，s，c），（namespace3.com.CoolAddress与领域house_num，street，city）。

The problem is that certain web services I use require certain Address object types so I am required to create a com.namespace1.Addressgiven a namespace3.com.CoolAddress. The fields are easy enough to map but I'm looking for a pattern on how to do it.

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

From my point of view, an instance object AddressConverterdoesn't make sense as there is no state (only behaviour) and when classes only have behaviour it boils down to static methods in a utility class. In the long term, anytime I need to map new objects to one another, I have one place to add/modify/remove methods. How it's done might change, but I know where the code sits (in once place) and can change the mapping when I need to.

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

Thoughts?

想法？

回答by dj_segfault

I think what you're looking for is a factory class. The factory pattern is used when you need to be able to instantiate one of several related classes, to be determined by the factory, not the developer.

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

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

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

You're right to try to keep all this business logic in one place instead of doing ClassOne.toClassTwo(), ClassOne.toClassThree(),...

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

The most flexible way I can think of implementing this (but not the easiest by far) would be to have the factory start with a simple class with only basic common methods in it, and add handlers to a Hashtable or other container. That way you don't need concrete implementations of every possible combinations of features.

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

Of course it would be quicker to have a concrete implementation for each possible address variant, but there would be a fair amount of duplicated code, and it would be a little harder to add new address class types.

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

回答by Brian Yarger

Since you can't modify the classes themselves, I'd suggest an implementation of the Adapterpattern for each direction. As you said, the adapter methods themselves can be static, but you can group both directions inside a single class so that the logic is all in one place.

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

At the end of the day you're going to be performing the same task no matter what you call it, or where you put the code. I'd suggest that both directions live in the same file, as they'll often both need updating when either direction changes.

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

回答by gjrwebber

If you are always converting to the same Class I would keep it simple and put all you conversion code in that Class and not worry about factories and the like, especially if you are only dealing with a couple of different classes. Why does there always have to be a complicated pattern for these things?!

如果你总是转换到同一个类，我会保持简单，把你所有的转换代码放在那个类中，而不用担心工厂等，特别是如果你只处理几个不同的类。为什么这些东西总得有一个复杂的模式？！

public class A {

    ...

    public static A convertB(B b) {

    ...

    }
}

回答by David Moles

Are the classes you need to output final? If not, you could subclass them to create proper Adapters. Otherwise I'd go with dj_segfault's suggestion of a Factory with a table of handlers.

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

Or, wait -- is it just a web service you need to talk to? If so, there should be no reason your implementations of its datatypes can't be Adapters wrapping the input datatypes, or some intermediate object of your own.

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