如何改进构建器模式？

Question

动机

最近我寻找一种无需向构造函数传递大量参数即可初始化复杂对象的方法。我尝试使用构建器模式，但我不喜欢这样的事实：我无法在编译时检查我是否确实设置了所有需要的值。

传统构建器模式

当我使用构建器模式创建我的 Complex 对象时，创建更加“类型安全”，因为更容易看出参数的用途：

new ComplexBuilder()
        .setFirst( "first" )
        .setSecond( "second" )
        .setThird( "third" )
        ...
        .build();

但现在我遇到了问题，即我很容易错过一个重要的参数。我可以在 build() 方法中检查它，但这只是在运行时。在编译时，如果我错过了什么，没有任何东西会警告我。

增强的构建器模式

现在我的想法是创建一个构建器，如果我错过了所需的参数，它会“提醒”我。我的第一次尝试如下所示：

public class Complex {
    private String m_first;
    private String m_second;
    private String m_third;

    private Complex() {}

    public static class ComplexBuilder {
        private Complex m_complex;

        public ComplexBuilder() {
            m_complex = new Complex();
        }

        public Builder2 setFirst( String first ) {
            m_complex.m_first = first;
            return new Builder2();
        }

        public class Builder2 {
            private Builder2() {}
            Builder3 setSecond( String second ) {
                m_complex.m_second = second;
                return new Builder3();
            }
        }

        public class Builder3 {
            private Builder3() {}
            Builder4 setThird( String third ) {
                m_complex.m_third = third;
                return new Builder4();
            }
        }

        public class Builder4 {
            private Builder4() {}
            Complex build() {
                return m_complex;
            }
        }
    }
}

如您所见，构建器类的每个设置器都会返回不同的内部构建器类。每个内部构建器类只提供一个 setter 方法，最后一个仅提供一个 build() 方法。

现在对象的构造再次看起来像这样：

new ComplexBuilder()
    .setFirst( "first" )
    .setSecond( "second" )
    .setThird( "third" )
    .build();

...但是没有办法忘记所需的参数。编译器不会接受它。

可选参数

如果我有可选参数，我将使用最后一个内部构建器类 Builder4 来设置它们，就像“传统”构建器一样，返回自身。

问题

• 这是一个众所周知的模式吗？它有一个特殊的名字吗？
• 你看到任何陷阱吗？
• 您是否有任何改进实施的想法 - 从减少代码行的意义上来说？

Answer 1

传统的构建器模式已经处理了这个问题：只需在构造函数中获取强制参数即可。当然，没有什么可以阻止调用者传递 null，但您的方法也不会。

我发现您的方法的一个大问题是，您要么具有大量强制参数的类组合爆炸，要么强制用户在一个特定的序列中设置参数，这很烦人。

此外，还有很多额外的工作。

Answer 2

public class Complex {
    private final String first;
    private final String second;
    private final String third;

    public static class False {}
    public static class True {}

    public static class Builder<Has1,Has2,Has3> {
        private String first;
        private String second;
        private String third;

        private Builder() {}

        public static Builder<False,False,False> create() {
            return new Builder<>();
        }

        public Builder<True,Has2,Has3> setFirst(String first) {
            this.first = first;
            return (Builder<True,Has2,Has3>)this;
        }

        public Builder<Has1,True,Has3> setSecond(String second) {
            this.second = second;
            return (Builder<Has1,True,Has3>)this;
        }

        public Builder<Has1,Has2,True> setThird(String third) {
            this.third = third;
            return (Builder<Has1,Has2,True>)this;
        }
    }

    public Complex(Builder<True,True,True> builder) {
        first = builder.first;
        second = builder.second;
        third = builder.third;
    }

    public static void test() {
        // Compile Error!
        Complex c1 = new Complex(Complex.Builder.create().setFirst("1").setSecond("2"));

        // Compile Error!
        Complex c2 = new Complex(Complex.Builder.create().setFirst("1").setThird("3"));

        // Works!, all params supplied.
        Complex c3 = new Complex(Complex.Builder.create().setFirst("1").setSecond("2").setThird("3"));
    }
}

Answer 3

不，这不是什么新鲜事。您实际上正在做的是通过扩展标准构建器来创建某种 DSL模式来支持分支，这是确保构建器不会为实际对象生成一组冲突设置的绝佳方法。

就我个人而言，我认为这是构建器模式的一个很好的扩展，你可以用它做各种有趣的事情，例如在工作中，我们有 DSL 构建器用于一些数据完整性测试，这允许我们做诸如 assertMachine( ).usesElectricity().and().makesGrindingNoises().whenTurnedOn();。好吧，也许不是最好的例子，但我想你明白了。

Answer 4

为什么不在构建器构造函数中放入“所需”参数？

public class Complex
{
....
  public static class ComplexBuilder
  {
     // Required parameters
     private final int required;

     // Optional parameters
     private int optional = 0;

     public ComplexBuilder( int required )
     {
        this.required = required;
     } 

     public Builder setOptional(int optional)
     {
        this.optional = optional;
     }
  }
...
}

Effective Java 中概述了此模式。

Answer 5

我不会使用多个类，而是只使用一个类和多个接口。它会强制执行您的语法，而无需输入太多内容。它还允许您紧密地查看所有相关代码，从而更容易在更大的级别上理解代码的情况。

Answer 6

恕我直言，这看起来很臃肿。如果您必须拥有所有参数，请将它们传递到构造函数中。

Answer 7

我已经看到/使用过这个：

new ComplexBuilder(requiredvarA, requiedVarB).optional(foo).optional(bar).build();

然后将它们传递给需要它们的对象。

Answer 8

当您有很多可选参数时，通常会使用构建器模式。如果您发现需要许多必需参数，请首先考虑以下选项：

• 您的类可能做得太多了。仔细检查它是否违反单一责任原则。问问自己为什么需要一个包含如此多必需实例变量的类。
• 您的构造函数可能做得太多 。构造函数的工作就是构造。 （他们在命名时并没有很有创意；D）就像类一样，方法也有单一职责原则。如果您的构造函数不仅仅执行字段赋值，那么您需要一个充分的理由来证明这一点。您可能会发现您需要工厂方法而不是构建器。
• 您的参数可能做得太少。问问自己，您的参数是否可以分组为一个小结构（或 Java 中的类似结构的对象）。不要害怕进行小班授课。如果您确实发现需要创建一个结构体或小型类，请不要忘记 重构 out 功能 属于结构而不是更大的类。

Answer 9

有关何时使用构建器模式及其优点的更多信息，您应该查看我的帖子以了解另一个类似的问题这里

Answer 10

问题1：关于模式的名称，我喜欢“Step Builder”这个名字：

• http://rdafbn.blogspot.com/2012/07/step-builder-pattern_28.html
• http://www.javacodegeeks.com/2013/05/building-smart-builders.html

问题2/3：关于陷阱和建议，感觉已经结束了对于大多数情况来说都很复杂。

• 您在使用构建器时强制执行顺序，这在我的经验中是不寻常的。我知道这在某些情况下很重要，但我从来不需要它。例如，我认为没有必要在这里强制执行序列：

  Person.builder().firstName("John").lastName("Doe").build()
Person.builder().lastName("Doe").firstName("John").build()

• 但是，很多时候构建器需要强制执行一些约束以防止伪造对象建造的。也许您想确保提供所有必填字段或字段组合有效。我猜这就是您想要在建筑物中引入排序的真正原因。

  在这种情况下，我喜欢 Joshua Bloch 的建议，在 build() 方法中进行验证。这有助于跨领域验证，因为此时一切都可用。请参阅此答案：https://softwareengineering.stackexchange.com/a/241320

总之，我不会添加任何代码变得复杂只是因为您担心“错过”对构建器方法的调用。在实践中，通过测试用例很容易发现这一点。也许从普通的构建器开始，然后如果您一直被缺少方法调用所困扰，则可以引入它。