使用静态内部构建器类的好处

在编写公司代码准则的过程中，我发现自己建议使用来自Effective Java 的Builder模式，而不是伸缩式构造函数。

但是，经过更多考虑之后，肯定是一个更优雅的解决方案是只删除构建器类，并且还要删除带有可选参数的多余构造函数。

因此，只有一个带有必需参数的构造函数，正常的getter / setter和注释代码。实现时，只需创建yr对象的新实例，然后设置值即可。

我最初的想法是，好处是消除了关于哪些参数是可选的以及需要哪些参数的困惑；但是，真正的好处来自使用方法链接/流利接口。

当您创建许多新实例时，构建器模式会很有用，因为ide可以完成繁琐的工作，并且还有很多（15+）个可选参数。但是，值得花额外的时间编码静态内部类吗，您是否建议使用构建器，还是浪费时间？

我倾向于遵循一种模式，即构造函数应提供创建有效且一致的对象所需的所有必需值。对于可选值，我尝试考虑最常见的默认值是什么，以便尽可能少地使用setter。

如果我发现有很多可选值，或者有较大比例的可选值倾向于从其默认值更改，那么我将使用构建器模式（静态内部构建器或其他类似设计）。

Josh通常会提供相当不错的好建议-我喜欢他的最好的建议是来自于战from-他承认自己在设计Java的某些部分时犯了错误，Effective Java在某种程度上是他的“治愈”方法，因此说:-)

Josh Bloch的Builder模式与GoF Builder模式非常相似，它提供了一种创建具有大量默认数据的不可变对象的方法，而无需一长串链式构造函数。

如果“拥有一个带有必需参数的构造函数，即普通的getter / setter”，则您的对象将不再是不变的。即。您可以在实例化它后很长时间对其进行更改。

如果这对您来说不是问题，那么您根本就不需要构建器模式。如果有问题，则您的解决方案有缺陷。