Java 什么'；对象到对象转换的设计模式是什么？

问题很简单。我需要将一个bean的内容转换成另一个具有不同getter和setter的bean。这样做的正确设计模式是什么

我认为适配器模式主要是指一个签名或接口到另一个签名或接口的映射。不是对象之间的真正映射

很多人都在谈论“mapper”，但我认为这不是一种设计模式

---

那么，实际上有一种模式可以将一个对象映射到另一个对象吗？

我不知道有任何流行的对象映射设计模式

我一直在使用Dozer框架将内容从一个bean传输到另一个bean

它使用简单，易于与Spring集成

参考：

---

我同意Javakid的观点，您需要的不是设计模式，而是处理从一个bean到另一个bean的te转换的好解决方案

若您真的需要命名，那个么应该类似于dto模式，因为您使用的是数据传输对象。在构建转换后的bean树时，可以使用访问者检查所有bean树

所以我建议使用一个框架或者自己开发映射，这取决于图的大小。Dozer是一个很好的解决方案，但它始终使用反射API并隐藏映射代码。因此，您将无法轻松地调试它，也没有其他运行时映射库像我所知道的最好的

但是，如果您希望能够看到代码，可以对其进行调试，还可以使用编译器反馈

最后一件事，您还可以向该线程报告处理java中bean到bean映射的解决方案的总体情况：

相关模式是在给定另一个对象的内容的情况下组装某个对象。由于编写汇编程序可能会很繁琐且容易出错，因此可以使用对象映射库来完成这项工作

---

您可能会签出一个对象映射器，它使用实际代码以安全的方式映射属性、字段和方法。

Microsoft发布了一个不错的转换器模式。本教程是C++，但应该很容易转换为java。 以下是一个教程：

一般的想法是，您有一个通用的Translator抽象类，它用您想要在其中转换的类类型参数化。具体实现提供了“to”和“from”转换方法

---

这种模式的优点是在转换过程中不需要两个类之间的耦合。它是在一个可重用的通用框架中实现这一点的，该框架不会使用一次性转换解耦逻辑使代码变得混乱

一个很好的“设计模式”是不要将映射对象彼此紧密耦合。例如，复制构造函数意味着如果编辑源类，还必须编辑目标类，这可能会在大型项目中导致各种下游问题。这样想吧。一个非常常见的映射是从UI数据结构到后端数据结构。您应该能够废弃UI，而不必为新UI更改后端。MVC设计模式经常用于此类工作。

您知道，并非所有的东西都需要成为一种模式。可能不需要提醒：并非所有东西都需要成为一种设计模式。设计模式只是常见的解决方案（根据定义），但它们不是唯一的解决方案。（事实上，你称事物为“bean”而不是“对象”，这让我觉得你认为一切都应该是一个设计模式）复制构造函数经常用于此。我会用“包装器”将其称为“桥”，它只用于？