对象转换模式
我有几个不同的类来自外部源（不可修改），代表相同的概念。 例如Address 。 我有com.namespace1.Address （包含字段houseNum ， street ， city ）， com.namespace2.Address （包含字段h ， s ， c ）， namespace3.com.CoolAddress （包含字段house_num ， street ， city ）。
问题是我使用的某些Web服务需要某些Address对象类型，因此我需要在给定namespace3.com.CoolAddress创建com.namespace1.Address 。 字段很容易映射，但我正在寻找一个如何做的模式。
从我的角度来看，实例对象AddressConverter没有意义，因为没有状态（只有行为），当类只有行为时，它归结为实用程序类中的静态方法。 从长远来看，无论何时我需要将新对象相互映射，我都有一个地方可以添加/修改/删除方法。 如何完成它可能会改变，但我知道代码所在的位置（在一次位置）并且可以在需要时更改映射。
思考？
我想你要找的是工厂级 。 当您需要能够实例化由工厂而不是开发人员确定的几个相关类中的一个时，将使用工厂模式。
见http://en.wikipedia.org/wiki/Factory_method_pattern
你是正确的尝试将所有这些业务逻辑保存在一个地方，而不是做ClassOne.toClassTwo（），ClassOne.toClassThree（），…
我能想到的最灵活的方法是实现这个（但不是最简单的）是让工厂从一个简单的类开始，只有基本的常用方法，并将处理程序添加到Hashtable或其他容器。 这样，您就不需要具体实现每种可能的function组合。
当然，对每个可能的地址变量进行具体实现会更快，但是会有相当多的重复代码，并且添加新的地址类类型会有点困难。
由于您无法自行修改类，因此我建议为每个方向实现适配器模式。 正如您所说，适配器方法本身可以是静态的，但您可以在单个类中对两个方向进行分组，以便逻辑全部在一个位置。
在一天结束时，无论您调用什么，或者放置代码，您都将执行相同的任务。 我建议两个方向都存在于同一个文件中，因为当两个方向都发生变化时，它们通常都需要更新。
如果你总是转换到相同的类我会保持简单，并将所有转换代码放在该类中，而不用担心工厂等，特别是如果你只处理几个不同的类。 为什么这些东西总是必须有一个复杂的模式？！
public class A { ... public static A convertB(B b) { ... } }
您需要输出的课程是final吗？ 如果没有，您可以将它们子类化以创建适当的适配器 。 否则我会选择dj_segfault的工厂建议和一个处理程序表。
或者，等等 – 它只是一个你需要与之交谈的网络服务吗？ 如果是这样，那么您的数据类型的实现不应该是包装输入数据类型的适配器，或者您自己的某个中间对象。