OO上的JavaWorld：GettersSetters与Builder

OO上的JavaWorld：Getters / Setters与Builder

问题1
：字符串解析似乎很奇怪。恕我直言，您只能做很多事来期待将来的增强。您可以

long

从一开始就确定使用参数，或者稍后考虑添加其他构造函数。或者，您可以引入可扩展参数类。见下文。

问题2 ：在几种情况下，构建器模式可能有用。

• 复杂对象创建

当您处理具有许多属性的非常复杂的对象时，最好在对象创建时仅对其设置一次，使用常规构造函数执行此 *** 作可能会变得难以阅读，因为构造函数将包含很长的参数列表。将其发布为API并不是一种好方法，因为每个人都必须仔细阅读文档，并确保不要混淆参数。

取而代之的是，当您提供一个构建器时，只需要处理带有所有参数的（私有）构造器，但是类的使用者可以使用可读性更高的单个方法。

设置器不是一回事，因为它们允许您在创建对象后更改对象属性。

• 可扩展的API

当您仅为您的类发布多参数构造函数，然后又决定需要添加新的（可选）属性（例如，在软件的更高版本中）时，您必须创建第二个与第一个相同的构造函数，但又需要一个参数。否则，如果只是将其添加到现有构造函数中，则会破坏与现有代码的兼容性。

使用构建器，您只需为新属性添加新方法，而所有现有代码仍然兼容。

• 不变性

软件开发正强烈趋向于并行执行多个线程。在这种情况下，最好使用无法创建的对象（不可变对象），因为这些对象不会导致来自多个线程的并发更新出现问题。这就是为什么不能使用setter的原因。

现在，如果要避免多参数公共构造函数的问题，那么将构建器作为非常方便的替代方法即可。

• 可读性（“ Fluent API”）

基于构建器的API可能非常易于阅读，如果构建器的方法命名巧妙，则可以编写出几乎像英文句子一样的代码。

通常，构建器是一种有用的模式，根据您使用的语言，对于API的提供者来说，它们要么真的很容易使用（例如Groovy），要么有点乏味（例如Java）。但是，对于消费者而言，它们可能同样容易。