到处使用Builder模式是好主意还是坏主意？

Question

最近，我和我的团队分享了用于单元测试的Builder模式(fluent样式)。

我个人喜欢在单元测试中使用这种模式，因为很多对象通常都是用不同的参数配置创建的。该模式有助于保持单元测试的简短性，特别是如果与对象母模式相结合的话。

现在这个团队的一些成员想要在项目的其他领域使用它，在我看来，它可能会传播到任何地方。

的含义是什么？

我知道建造者是有成本的，但既然我们已经有他们，为何不使用他们呢？

Answer 1

每个人都想要一颗能让他们关闭大脑的银弹。这也不是它。

对象结构及其相关的创造模式，是一个多种多样的事物。

我猜你指的是约书亚·布洛赫的建筑图案。如果您想要一个不可变的对象，并且需要模拟命名的参数，这是很好的，因为您的语言没有它们。

但是掌握布洛赫的建造者并不能成为忽视所有其他造物模式和技巧的借口。工厂方法、抽象工厂、GoF构建器，甚至是备受诟病的单例模式，都有需要考虑的情况。

信不信由你，布洛赫的“建设者”甚至可以在流畅的建筑领域中脱颖而出。研究构建的eDSL模式，您将能够在编译时强制执行构造规则。这是不错的，但需要相当多的工作来建立，而且并不总是需要的。

你可能喜欢你那闪亮的新锤子，但请不要假装一切都是钉子。

Answer 2

模式只有在使用不当或不适合特定用例的情况下才是坏的。构建器模式通过在所有实例变量上使用最终修饰符来鼓励不可变性，而不需要设置所有必须设置的超长构造函数，但是对于只有少量异构字段的对象来说，这可能是过分的。

此外，强制性+可选成员字段是有效Java中描述的Builder模式的一个特性，但是，这也可能意味着无法在编译时判断是否设置了所有必需的字段(在运行时获得NPE )--因此必须为所有必要字段提供默认值以避免这种情况发生。

Answer 3

你写的

但既然我们已经有了，为什么不用呢？

因此，我想您是在专门讨论已经为单元测试实现了Builder的情况，现在考虑在单元测试之外重用它吗？这可能很好，只要您没有在代码质量方面做出任何妥协，因为“它只是支持测试的代码，所以它不必是干净的”-mindset。然后，使用Builders的单元测试就会自动成为测试，不仅是针对主要的“测试主题”，而且也是对那些构建者的测试，因此这里确实没有额外的成本。

让我补充一下，您的字面问题读起来完全不同：“在任何地方使用Builder”这个短语给我的印象是，有人为每个类介绍了Builders，即使它们有零个或一个构造函数参数。这将是相当无用的开销，没有明显的好处，我认为这是相当不言自明的原因，这没有多大意义。