构建对象答案

【问题标题】：Building an object构建对象
【发布时间】：2010-12-03 04:57:36
【问题描述】：

我在这个博客中遇到了一种非常不寻常的方式来构建一个类的对象： http://marchwicki.pl/blog/2010/11/building-a-pojo-in-an-elegant-way/。这是一个很好的方法来做到这一点。有什么好处？

【问题讨论】：

谁能解释为什么要打扰内部类？为什么不直接从每个 setter 中返回对象？
@box9 - 内部类是构建器设计模式的构建器，所以您的问题本质上是“为什么要使用构建器设计模式”。请参阅下面有关构建器设计模式的答案以及有关构建器设计模式的其他 SO 问题的答案，例如 stackoverflow.com/questions/328496/…。
@Bert F - 我从那个 SO 问题中得到的是 Builder 模式允许将 setter 方法链接起来，这是我理解的。但这仍然不能解释为什么构建器模式比从每个设置器返回对象更好，因为这将还允许设置器的链接。我错过了 Builder 模式的好处吗？
@box9 - 我觉得你真的在问“为什么不使用简单的构造函数和 setter 方法来初始化一个对象？（又名 JavaBean 初始化风格）。不管你是否返回来自setter的实例，因此您可以链接setter - 链接只会影响代码的可读性。这个答案解释了为什么有些人更喜欢构建器模式而不是JavaBean风格的init：stackoverflow.com/questions/328496/…。如果仍然不清楚，我认为这会很好所以问题要问并获得一些关于它的其他观点。

标签： java design-patterns object constructor

【解决方案1】：

我在这个博客中遇到了一种非常不寻常的方式来构建一个类的对象：http://marchwicki.pl/blog/2010/11/building-a-pojo-in-an-elegant-way/。

这是具有流畅界面的构建器设计模式。

正如您从文章中看到的，这两个想法是互补的，并且经常一起使用（我见过一些人将其称为“流畅的构建器”），以至于它们经常被混淆同样的事情：

builder pattern 将复杂对象的构造抽象化并简化为更简单的步骤。
- “四人帮”的 Design Patterns 书中讨论了构建器模式
- Joshua Bloch 在他的书中Effective Java
fluent interface 是一种 API 样式，它使用上下文和方法链接来提高代码的可读性。
- 参见 Martin Fowler 关于流畅接口的帖子：
  http://www.martinfowler.com/bliki/FluentInterface.html

请注意，您可以在没有流畅界面的情况下使用构建器模式（例如，带有简单设置器的构建器）。您还可以在更多的上下文中使用流畅的接口理念，而不仅仅是构建器（例如，提高一组具有许多参数和参数变化的重载方法的可读性）。

这是一个好方法吗？

这个“流畅的构建器” 似乎被高度接受为“实现此目的的好方法”（至少基于我看到的宣传该想法的文章和博客文章的数量）。 p>

有什么好处？

每个想法都有其独特的优势/好处。例如，参见：

生成器 - When would you use the Builder Pattern?
Fluent 界面 - What's a fluent interface?

【讨论】：

【解决方案2】：

唯一的好处是可读性。顺便说一句，这是fluent interface 的示例。

流畅的接口旨在提供一种 API，当使用该 API 时，它会生成比标准 OOP API 倾向于提供的更具可读性的代码。

【讨论】：

不也叫builder-pattern吗？
@Srinivas：流利的接口是构建器模式的扩展。或者也许是 Java 中构建器模式的可读改编/实现，带有大量 DSL 知识。

【解决方案3】：

是的，这就是 Joshua Bloch 在他的“Effective Java”中 Chapter 2 的想法。

【讨论】：

【解决方案4】：

这是Builder pattern 的一个简单示例。它允许将用于创建复杂对象的算法与构成对象的部分以及它们的组装方式分开。 GoF 将这种模式的后果解释为：

它可以让您改变产品的内部表示。建设者对象提供了一个抽象构造接口产品。该界面让生成器隐藏表示和产品的内部结构。它还隐藏了产品的获取方式组装。因为产品是通过抽象构造界面，您所要做的就是改变产品的内部表示是定义一种新的建设者。

它隔离了构造和表示的代码。建设者模式通过提高模块化封装复杂对象的方式被构造和表示。客户不需要知道任何事情定义产品的类内部结构;这样的课程不出现在 Builder 的界面中。每个 ConcreteBuilder 包含所有代码创建和组装一个特定的一种产品。代码写好了一次;那么不同的客户可以重用它来构建产品变体来自同一组零件。

它可以让您更好地控制构建过程。不像构造的创造模式一站式产品，建造者模式逐步构建产品步骤在用户的控制下构建器对象。只有当产品完成了用户从构建器中检索它。因此 Builder 界面反映了构建产品的过程比其他创造模式更多。这使您可以更好地控制施工过程，因此内部结构生成的产品。

此模式的一个真实示例是 Smalltalk-80 编译器子系统中的 ProgramNodeBuilder 类。源代码由Parser 类的对象解析，该对象使用ProgramNodeBuilder 初始化。 Parser 对象在每次识别语法结构时都会通知其ProgramNodeBuilder 对象。解析器完成后，它会向构建器询问它构建的解析树并将其返回给客户端。

【讨论】：

【解决方案5】：

我很高兴在这里发表我的第一篇 stackoverflow 帖子 - 因为您正在讨论我的文章 :-)

我认为这种构造（构建器和流式接口的杠杆作用：流式构建器）极大地提高了代码的可读性。更重要的是（而不是围绕设计模式进行讨论）当我们需要不可变对象时，它证明了它的价值。简单地说，通过将构造函数设为私有并删除所有设置器，我们获得了一个非常强大的工具，可以以一种优雅、可读但强大的方式构建不可变对象。最后，整篇文章应该更多地是关于如何巧妙地使用模板来生成可重复的代码——但我非常喜欢这个讨论。

【讨论】：

欢迎来到论坛！如果您想了解更多关于我的项目的信息，请给我留言。

【解决方案6】：

我个人认为使用具有流畅界面的 Builder 非常有用且非常直观。在向构建器发送消息时，您可以更好地表达您的意图。

我写了一个带有 Fluent Interface 的 Builder 的小例子，希望对你有所帮助。

http://jpereira.eu/2011/10/12/fluent-interfaces-while-trying-to-make-sense-of-prototype-pattern/

【讨论】：