Question

我最近一直在与一个研究小组一起研究设计模式，并且已经认识到构建器模式对于创建由许多（可能是可选的）部分组成的复杂对象非常有用。

但是，建造者做得太多了吗？假设我们有一个具有许多不同对象组合的类，是否有另一种模式可能更适合它而不是制作数十种不同的构建器？是否可以通过不制作完全特定的构建器来减少所需的构建器数量？

我的研究小组和我一直回来的例子是汽车制造商，例如在汽车公司的网站上。任何汽车公司都有几十辆汽车，每辆汽车都有许多不同的功能，颜色，附加功能等。我理解它的方式，你的构建器应该特定于你正在制作的对象，所以在这个例子中应用构建器模式将产生数百个看起来像“RedSUVWithSunroofBuilder”，“BlueSUVWithSunroofBuilder”，“RedSUVBuilder”等的构建器。

有没有理由使用构建器模式，我无法传递其中一些值来减少我需要创建的构建器数量？例如，不是使用RedSUVWithSunroofBuilder或BlueSUVWithSunroofBuilder，它仍然适合构建模式来执行SUVWithSunroofBuilder（“Red”）和SUVWithSunroofBuilder（“Blue”），还是更适合不同的模式？

Answer 1

构建器模式当然是自由裁量的，如果它过于复杂则过于复杂，您可能需要考虑另一种创建对象的方法，例如factory pattern。我认为构建器模式有一些优势：

创建具有多个有效配置的对象
- 我认为你的汽车是一个很好的例子
创建不可变对象，而不能预先提供所有必需数据
- 有关这方面的一个很好的例子，请查看番石榴不可变集合构建器，例如ImmutableSet.Builder

以下是如何实施汽车制造商的一个示例：

public class Car {
    private final boolean hasSunroof;
    private final Color color;
    private final int horsePower;
    private final String modelName;

    private Car(Color color, int horsePower, String modelName, boolean hasSunroof) {
        this.color = color;
        this.horsePower = horsePower;
        this.hasSunroof = hasSunroof;
        this.modelName = modelName;
    }

    public static Builder builder(Color color, int horsePower) {
        return new Builder(color, horsePower);
    }

    public static class Builder {
        private final Color color;
        private final int horsePower;
        private boolean hasSunroof;
        private String modelName = "unknown";

        public Builder(Color color, int horsePower) {
            this.color = color;
            this.horsePower = horsePower;
        }

        public Builder withSunroof() {
            hasSunroof = true;
            return this;
        }

        public Builder modelName(String modelName) {
            this.modelName = modelName;
            return this;
        }

        public Car createCar() {
            return new Car(color, horsePower, modelName, hasSunroof);
        }
    }
}

Builder不必是嵌套类，但它允许您隐藏可能滥用API的人的构造函数。另请注意，必须提供最低必需参数才能创建构建器。您可以像这样使用此构建器：

Car car = Car.builder(Color.WHITE, 500).withSunroof().modelName("Mustang").createCar();

Answer 2

好吧，几个月前我想知道同样的问题，我想出了一个名为step builder pattern（full description of this pattern here）的新设计模式。

在这个设计中，我提供了设计路径的可能性，避免了创建多个构建器的需要。

概念很简单：

在内部类或接口中编写创建步骤，其中每个方法都知道接下来可以显示的内容。
在内部静态类中实现所有步骤接口。
最后一步是BuildStep，负责创建您需要构建的对象。

Answer 3

您通常会看到的Builder模式（特别是在Java中）是给定对象的单个Builder，它具有用于设置不同参数的流畅接口。这是Effective Java中提出的模式，这就是为什么你通常会在Java中看到它。

如果您有一些非常不同的构建场景，当然，不同的构建器对象可能有意义，但我会在这里退一步。如果一个对象中有这么多不同的属性，则可能有一个对象做得太多，问题的症状就是构建器的复杂性。

当然，现实世界的对象很复杂，但面向对象设计的基本论点是，如果复杂性在抽象中分层，那么在任何给定的层次，你一次处理5到7个属性，你可以限制变得过于复杂而无法在给定层理解的问题。

正确设计抽象层的难度使得上述理想主义与现实一样多，但我认为拥有一个对象做得太多了。

在你的汽车示例中，汽车有很多层，但保持可管理性的诀窍是区分不同的组件，并让更大的汽车由几个装配选项构成，这些装配选项本身由几个装配选项构成每个程序集都应该有自己的对象，可能还有它自己的构建器。

Answer 4

在我看来，你使用了太多的构建器，而且每个构建器都做得不够。每个类应该有一个构建器。您似乎正在尝试为每组字段值创建新构建器。相反，每个字段在一个构建器中应该有一个或两个方法。您的构建器调用最终应该看起来像这样

Car c = new SUVBuilder().withSunroof().withColor("Red").build();

以上假设SUV是汽车的子类。如果不是，那么您可以在附加功能中指定SUV。

Answer 5

构建器允许您将一系列复杂的选项封装到一个简单的算法中。例如，如果您的AssemblyLine正在构建汽车，则可能是：

buildChassis();
buildDriveTrain();
buildBody();
assemble();
paint();

您可能需要为不同的底盘，传动系和车身分别使用单独的混凝土制造商，但是您可能只需要使用一个用于油漆的工具 - 您只需将其参数化为颜色即可。你的导演课知道你的建造者的细节是什么，所以它实例化了正确的混凝土建造者;您的装配线客户端只是按顺序运行这些步骤。您可以为具体构建器参数化任何非基本的细节（以及判断调用的基本内容）。

建造者模式可能做得太多了吗？

5 个答案: