是否有一个约定，使用Builder模式创建的对象是不可变的？ [英] Is there a convention that objects created using the Builder pattern be immutable?

问题描述

根据设计模式：可重用的面向对象软件的元素：

According to the book Design Patterns: Elements of Reusable Object-Oriented Software,:

构建模式对象从它的表示，以便相同的构造过程可以创建不同的表示。

The Builder Pattern separates the construction of a complex object from its representation so that the same construction process can create different representations.

一般Builder模式解决了大量问题可选参数和不一致状态，通过提供一种逐步构建对象的方法，并提供一个实际返回最终对象的方法。

In general the Builder pattern solves the issue with large number of optional parameters and inconsistent state by providing a way to build the object step-by-step and provide a method that will actually return the final Object.

使用构建器模式，我们使用一个构建方法来生成一个不可变的对象。

With the builder pattern we go to have a build method to generate an object witch is immutable.

问题：

我可以在生成对象的类中使用构建器模式保持setters方法，允许改变构建的对象吗？

Can I use the builder pattern keeping setters methods in the Class of the generate object, allowing the possibility to mutate the built object ?

如果我去生成可变对象，我不应该使用构建器模式？

If I go to produce mutable objects, I shouldn't use the builder pattern ?

推荐答案

Builder模式中的价值超过了帮助解决伸缩参数问题。

There is value in the Builder Pattern than goes beyond just helping to solve the telescoping parameter problem.

• 他们可以让客户端更容易使用API​​，因为setter方法是自命名的，因此更容易记住。


• 构建器模式启用可选参数，只有通过使用可能令人尴尬的重载才能提供给可伸缩构造函数。


• 使用构建器的客户端代码比使用


• 构建器模式可以减少错误。相同类型的参数的大列表可能被伸缩构造函数意外转置。在这种情况下，编译器不会报告错误，并且导致的错误可能会被删除并难以跟踪。


• 对象的强制参数可以在构造函数签名中指定建设者。编译器将坚持在编译时始终提供这些强制性参数。


• 有用的API随着时间的推移而变化;很容易将setter方法添加到构建器对象，而管理一组重载的构造函数可能不太容易并且更容易出错。


• 构建器模式是并发的。

• They can make an API easier to use by clients since the setter methods are self-naming and, therefore, easier to remember.
• The Builder Pattern enables optional parameters, something that is offered with telescoping constructors only by using potentially awkward overloading.
• Client code that uses builders can be more self-documenting than code that uses constructors, enabling client code to be easier (and cheaper) to maintain
• The Builder Pattern can reduce bugs. Large lists of identically typed parameters can be accidentally transposed with telescoping constructors. In such a case, the compiler won't report the error and the resulting bugs can be far removed and hard to track down.
• Mandatory parameters for objects can be specified in the constructor signature for the Builder. The compiler will insist that these mandatory parameters are always provided at compile time.
• Useful APIs evolve over time; it is easy to add setter methods to a builder object, while it can be less easy and more error-prone to manage a set of overloaded constructors.
• The Builder Pattern is concurrency friendly. It is relatively straightforward to keep the mutable builder object thread confined and, therefore, threadsafe.

构建器对于构造不可变对象特别有用，因为，对于这样的对象，所有的数据必须在构建时提供。当有大量数据需要提供或者必须完成多个步骤时，构建器模式很容易推荐。

Builders are especially useful for constructing immutable objects because, for such objects, all the data must be supplied at build time. When there is a large amount of data to supply or when multiple steps must be completed, the Builder Pattern is pretty easy to recommend.

没有规则，构建器对象可以但是对于可变对象，JavaBeans模式通过较少的代码提供了相同的优点（易于可读性，自我文档化，降低错误的可能性）。

There is no rule that builder objects can't build mutable objects, however for mutable objects the JavaBeans pattern provides the same benefits (easy readability, self-documentation, reduced error prone-ness) with less code.

这篇关于是否有一个约定，使用Builder模式创建的对象是不可变的？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！