java - 不同 Java 类型之间的转换器

Question

我正在尝试在java中实现不同类型之间的转换器:我有一个父类(super class) foo，它有 2 个子类:foo1 和 foo2，我还有 2 个不相关的其他类 bar1 和 bar2，我正在尝试实现一个从 bar1 到 foo1 以及从 bar2 到 foo2 (以及相反)的转换器。

因为我在这里有继承，所以我认为应该创建一个具有泛型类型的接口(interface)(将是 bar1 或 bar2)，它将定义发生转换所需的函数，我也希望转换器是一个泛型bar1 和 bar2 的转换器，我认为它应该以某种方式使用接口(interface)实现。如果有更好的想法或引用此类实现示例，我们将不胜感激。我也在寻找一种描述这种方案的设计模式，但可以找到合适的模式......有什么想法吗？

Answer 1

我会选择一个公共(public)接口(interface)和一个公共(public)父类，并且可能还使用构建器模式......；

a common partialFooBar interface
a common fooBarChimera parent class

然后，您可以将转换器放入 fooBarChimera 父级中(并强制执行所需的额外详细信息，以最终确定您想要的任何内容。

您可能还想使用构建器模式。

稍微充实一下......

即第一类

partialFooBarBuilder

有一个简单的默认构造函数和设置方法。

最后的方法会将此类“转换”为“完整”版本，或 fooBarChimera，其中只需要有“getter”方法。

正确的版本只能从此构建器类(或 fooBarChimera)中获得，因此您可以在返回最终正确的 foo 类之前更轻松地强制内容处于良好状态(如果它链接到您的用户界面)。

所以你最终会得到类似的东西......

public class buildpartFooBar implement fooBarCommon{
//fooBarCommon is the interface the enforces the commonality of between the 2 objects.    

public buildPartFooBar(){...}

...[various setter methods here ....]

//make the different types of object we may become
private foo1 makeFoo1(iNeedThisToBeAFoo1 object){...}
private  foo2 makeFoo2(iNeedThisToBeAFoo2 object){...}
private  bar1 makeBar1(iNeedThisToBeABar1 object){...}
private  bar2 makeBar2 (iNeedThisToBeABar2 object){...}
private fooBarChimera makeChimera (){...}

}//buildPartFooBar 类结束

包含一个 makeFooFromBar 方法很简单，您可以在其中返回 foo1 或 Foo2 或任何您喜欢的内容，您可能会通过 fooBarChimera 类中的静态方法来执行此操作

请记住，您将需要处理转换后的 bar 和 foo 类彼此相关的情况(您可能需要实现某种形式的具有 bar 键和 foo 对象的集合，或者也许应该实现这一点在你的 fooBarChimera 某处)。

您可能会认为 foo 和 bar 也需要类似的方法，例如，将这些方法包含在 fooBarChimera 中作为静态比较可能是明智的。这样你只需要在父级中编写一次。

couldThisFooBeBar

和

couldThisBarBeFoo

因此，在创建时，您可以比较它们并决定是否应自动链接它们，然后如果链接已存在于您的集合中，则可以节省转换操作。

您还需要确定转换是否为 2 路，一个 foo 可以是一个 bar，但一个 bar 可能与 2 个 foo 兼容。

在这种情况下，您可能决定转向可以处理此类事情的数据库并在其中存储您的 foo 和 bar 对象，它也可能比自定义集合类更容易，特别是如果您给每个 foo 和禁止唯一的 objectID (guid)。

它可能会变得更加高级......这取决于您打算将其带到哪里，听起来像是您为自己设定的一项有趣的任务，我们可以问您为什么要这样做吗？

我可能只是为了好玩而做的事情......就像当我根据java集合对遗留数据库进行建模时，只是意识到我是多么愚蠢，然后将其转换为更明智的数据库。

大卫