design-patterns - Builder.build() 应该返回默认状态吗？

Question

使用 Builder 模式时，总是存在字段是否有默认值的问题？我找不到一个明确定义的可靠来源......

问题是可读性:什么是 Car.Builder().build()回来？我总是需要检查Builder的具体实现查看使用了哪些默认值。不应该使用 Builder 来创建根据定义没有简单默认状态的复杂对象吗？

另一种方法是检查是否所有必填字段都设置在 build() 内。方法:

fun build() : Car {
    return if (doors != null && hp != null) Car(doors, hp, color) // color can be null
    else throw IllegalArgumentException("Door count and HP is mandatory!")
}

...或者这被认为是不好的做法？

Answer 1

您没有找到问题的一般答案，因为没有。这取决于构建器所使用的上下文或构建器正在构建的对象的详细信息。

有时，返回一个默认对象是完全合理的，它的所有成员都被初始化为默认值。但是这个默认对象必须是有效的。例如。要构建一个记录器对象，返回一个记录到控制台的记录器是有效的，该记录器具有默认格式和默认日志级别。有人可以立即使用它。

但有时纯粹的默认对象没有意义。创建一个完全配置的默认 HTTP 客户端是不明智的，因为它不会提供最小的预期行为，因为目标 URL 可能是意外的。在这种情况下，您可以为构建器类编写一个构造函数，该构造函数将 URL 作为参数(也可能是某些数据对象)，然后使用默认值(例如，默认请求 header 、默认超时、默认缓冲区大小等)预配置客户端对象.然后，该对象将满足最低使用预期。每次后续调用 setter 都将覆盖默认值，其中每个 setter 应在接受参数之前检查参数的有效性。

但是您应该始终在可能的情况下尝试使用默认值而不是异常。当一个对象的构造需要强制性信息时，然后通过将它们放入构造函数来公开它。这样您就可以安全地确保您的对象始终处于有效且有用的状态。在 HTTP 客户端构建器的情况下，如果 URL 格式错误，您可以抛出异常，以提示开发人员其构造 URL 的代码可能存在缺陷。也许阅读 Best practices for exceptions .

考虑到编写构造函数以收集所有必需参数(无法设置为有用的默认值)的解决方案，您的 build() finalize 方法可以并且应该始终并且在任何时候返回一个有效且有用的对象。这使您的构建器方便。 (否则构建器的用户将被迫阅读文档以了解要调用哪些 setter。每个人都知道您不喜欢编写文档。每个人都知道您不喜欢在使用某些类之前阅读文档。大家都有同感)。