构建一个对象
我在这个博客中遇到了一种非常不寻常的方法来构建一个类的对象： http ： //marchwicki.pl/blog/2010/11/building-a-pojo-in-an-elegant-way/ 。 这是一个很好的方法来做到这一点。 有什么好处？
我在这个博客中遇到了一种非常不寻常的方法来构建一个类的对象： http ： //marchwicki.pl/blog/2010/11/building-a-pojo-in-an-elegant-way/ 。
这是具有流畅界面的构建器设计模式 。
正如你从文章中看到的那样，这两个想法是互补的并且经常一起使用（我已经看到一些人称之为“流利的建设者” ），所以，他们经常被混淆为同样的事情：
-
构建器模式将复杂对象的构造抽象并简化为更简单的步骤。
-
构建器模式在“四人帮”的设计模式书中讨论
-
Joshua Bloch在他的“ Effective Java”一书中讨论了建设者作为第2项
-
-
流畅的接口是一种API风格，它使用上下文和方法链来提高代码的可读性。
- 请参阅Martin Fowler关于流畅界面的post：
http://www.martinfowler.com/bliki/FluentInterface.html
- 请参阅Martin Fowler关于流畅界面的post：
请注意，您可以在没有流畅界面的情况下使用构建器模式（例如，具有简单setter的构建器）。 您还可以在更多上下文中使用流畅的界面构思，而不仅仅是构建器（例如，为了提高具有许多参数和参数变化的一组重载方法的可读性）。
这是一个很好的方法吗？
这个“流利的建设者”似乎被高度认可为“这样做的好方法”（至少根据我看过的改变这个想法的文章和博客文章的数量）。
有什么好处？
每个想法都有其独特的优势/好处。 例如，请参阅：
-
构建器 – 您何时使用构建器模式？
-
流畅的界面 – 什么是流畅的界面？
是的，这就是Joshua Bloch在他的“Effective Java” 第2章中的想法。
这是Builder模式的一个简单示例。 它允许将用于创建复杂对象的算法与构成对象的部分及其组合方式分离。 GoF解释了这种模式的后果：
- 它可以让您改变产品的内部表示 。 Builder对象提供了用于构造产品的抽象接口。 界面允许构建器隐藏产品的表示和内部结构。 它还隐藏了产品的组装方式。 因为产品是通过抽象接口构建的，所以您只需要更改产品的内部表示，就可以定义一种新的构建器。
- 它隔离了构造和表示的代码 。 Builder模式通过封装构造和表示复杂对象的方式来提高模块性。 客户不需要了解定义产品内部结构的类; 这些类不会出现在Builder的界面中。 每个ConcreteBuilder都包含创建和组装特定类型产品的所有代码。 代码写一次; 然后，不同的客户可以重复使用它来从同一组零件构建产品变体。
- 它可以让您更好地控制施工过程 。 与一次构建产品的创建模式不同，Builder模式在构建器对象的用户的控制下逐步构建产品。 只有在产品完成时，用户才会从构建器中检索它。 因此，Builder界面比其他创作模式更能反映构建产品的过程。 这使您可以更好地控制施工过程，从而控制最终产品的内部结构。
这种模式的一个真实例子是Smalltalk-80编译器子系统中的ProgramNodeBuilder类。 源代码由Parser类的对象解析，该对象使用ProgramNodeBuilder初始化。 Parser对象每次识别语法结构时都会通知其ProgramNodeBuilder对象。 解析器完成后，它会向构建器询问它构建的解析树并将其返回给客户端。
我很高兴在这里做我的第一篇stackoverflowpost – 因为你正在讨论我的文章:-)
我认为这种结构（兼容构建器和流畅的界面：流畅的构建器）极大地提高了代码的可读性。 更重要的是（并没有围绕设计模式进行讨论），当我们需要不可变对象时，它certificate了它的价值。 简单地说，通过使构造函数私有并删除所有setter，我们获得了一个非常强大的工具，用于构建不可变对象的优雅，可读但强大的方法。 最后，整个post应该更多地关于模板的智能使用以生成可重复的代码 – 但我非常喜欢讨论。
我个人觉得使用带有Fluent界面的Builder非常有用且非常直观。 在向构建器发送消息时，您可以更好地表达您的意图。
我写了一个带有Fluent Interface的Builder的小例子，希望它有所帮助。
http://jpereira.eu/2011/10/12/fluent-interfaces-while-trying-to-make-sense-of-prototype-pattern/