从更复杂的对象构建对象的设计模式答案

【问题标题】：Design Pattern for building an object from a more complex object从更复杂的对象构建对象的设计模式
【发布时间】：2009-07-16 21:49:50
【问题描述】：

我正在重构我当前项目的一些代码，我想了解以下情况是否存在任何设计模式。

我有一个类执行一些逻辑并返回一个包含所述逻辑结果的对象；我们称它为 Result 对象。 Result 对象中包含的状态信息是基于更复杂的对象 Intermediary 对象构建的。

现在从 Intermediary 对象填充 Result 对象的代码已经存在，但由于我正在重构，我想让它更简洁。我正在考虑创建一个单独的类，可能称为 ResultBuilder，它有一个静态执行方法，该方法以 Intermediary 作为输入并吐出 Result 作为输出。

是否有与“ResultBuilder”类等效的设计模式？有没有更好的方法从中间对象构造 Result 对象？

【问题讨论】：

【解决方案1】：

我相信你想要工厂模式。

【讨论】：

【解决方案2】：

您似乎已经有了解决方案，那么为什么您发现需要一些外部资源来为您命名，这样它才会变得更有效？
如果它对您有意义，并且确实让事情变得更清晰、更清晰，那就去做吧，不要过多考虑名称和标签。

【讨论】：

这样以后任何处理代码的人只需要看到工厂这个词并理解其意图吗？模式背后的全部原理是用共同的词汇来传达共同的设计。
因为已记录在案的模式中的思考和改进可能有助于通知和增强 Todd 的设计。因为它可能是一个已解决的问题，并且应用现有的解决方案比从头开始创建一个解决方案更容易。因为现有的解决方案可能比他自己的解决方案更强大。因为我们向社区学习。
我同意设计模式作为一种文档机制很有用，但作为一种解决问题的方法，它充其量是有限的。

【解决方案3】：

为什么Result 不能有一个接受Intermediary 实例的构造函数？

【讨论】：

【解决方案4】：

建造者模式！

虽然它通常是一个多部分的构建过程....如果它只制造一件事，那么它更像是一个工厂....

它是标准的 GOF 模式

【讨论】：

【解决方案5】：

我建议研究Builder 和Factory 模式，这两种模式都是四人组模式。 Wikipedia 上都有这两者的示例，Java 中也不少。

【讨论】：