Builder设计模式：为什么我们需要Director？

Question

最近我遇到了 Builder 设计模式。似乎不同的作者使用“构建器模式”来指代不同的风格，所以让我描述一下我所询问的模式。

我们有一个创建产品的算法，即不同类型的对象。在足够高的抽象级别上，算法对于所有产品类型都是相同的，但每种产品类型都需要对算法的每个抽象步骤进行不同的实现。例如，我们可能有以下蛋糕烘焙算法：

 1. Add liquids.
 2. Mix well.
 3. Add dry ingredients.
 4. Mix well.
 5. Pour batter into baking pan.
 6. Bake.
 7. Return baked cake.

不同的蛋糕需要对这些步骤进行不同的实现，即使用什么液体/干成分、以什么速度混合、烘烤多长时间等。

该模式表示像这样做。对于每个产品，我们创建一个具体构建器类，其中包含上述每个步骤的实现。所有这些类都派生自抽象构建器基类，该基类本质上是一个接口。因此，例如，我们将有一个抽象基类 CakeBaker ，具有纯虚方法 AddLiquid()、MixLiquids() 等。具体蛋糕烘焙师将是具体的子类，例如，

class ChocolateCakeBaker : public CakeBaker {
public:
   virtual void AddLiquids()
   {
        // Add three eggs and 1 cup of cream
   }

   virtual void AddDryIngredients()
   {
       // Add 2 cups flour, 1 cup sugar, 3 tbsp cocoa powder,
       // 2 bars ground chocolate, 2 tsp baking powder
   }
      ...
      ...
};

LemonCitrusCakeBaker 也将是 CakeBaker 的子类，但会在其方法中使用不同的成分和数量。

不同的蛋糕类型同样是抽象 Cake 基类的子类。

最后，我们有一个类来实现抽象算法。这是导演。在面包店示例中，我们可以将其称为“ExecutiveBaker”。此类将接受（来自客户端）具体的构建器对象并使用其方法来创建和返回所需的产品。

这是我的问题。为什么我们需要将主管与抽象构建者分开？为什么不将它们放入单个构建器抽象基类中，使原始抽象构建器的公共方法受到保护（并且具体子类像以前一样覆盖这些方法）。

Answer 1

构建器模式的核心部分涉及抽象构建器及其子类（具体构建器）。根据 GoF 的设计模式，director 只是“每当需要构建产品的一部分时通知构建者”，这可以通过客户。

Java API 中的 StringBuilder 类是一个构建器示例，没有相应的导演——通常是客户端类“指挥”它。

另外，在 Effective Java 和 创建和销毁 Java 对象，Joshua Bloch 建议使用构建器模式，并且他不包括导演。

Answer 2

Builder 模式的 GoF 变体没有 Builder 没有 Director。这有一个不同的点，但我会进一步解释。

构建器模式的要点是为您提供多种方法来创建同一对象。 Builder 应该只具有构建对象不同部分的方法，但算法（这些函数的执行方式）应该是 Director 关心的问题。如果没有总监，每个客户都需要确切地了解建筑物的运作方式。但是对于Director，客户需要知道的是在特定情况下使用什么Builder。

所以，我们这里有两个部分：

1. Builder，它一一创建对象的各个部分。需要注意的重要一点是，为此它会保留创建对象的状态。
2. Director，控制 Builder 函数的执行方式。

现在回到我之前提到的这一点。该模式的 Builder 部分在其他情况下很有用，并且已被不同的供应商在没有 Director 的情况下用于不同的目的。此类使用的具体示例是 学说查询生成器。

这种方法的缺点是，当构建器开始构建对象时，它就会变得有状态，并且如果客户端在创建对象后没有重置构建器 - 另一个客户端或已多次使用的同一客户端可以获得部件之前创建的对象的名称。因此，Doctrine 使用工厂模式来创建 Builder 的每个实例。

我希望这对那些谷歌搜索的人有所帮助。

Answer 3

如果您分为总监和建造者，则您已记录了从一组零件组装产品的不同责任（总监）和创建零件的责任（建造者）。

• 在构建器中，您可以更改零件的构建方式。根据您的情况，AddLiquid() 是否应该添加奶油或牛奶。
• 在director中，您可以更改部件的组装方式。在您的情况下，通过使用 AddChocolate() 而不是 AddFruits() 您会得到不同的蛋糕。

如果您想要这种额外的灵活性，我将重命名为（因为在构建器中使用面包师表明，这是构建器组装零件的工作）

class LightBakingSteps : public BakingSteps {
public:
    virtual void AddLiquids()
    {
        // Add milk instead of cream
    }

    virtual void AddDryIngredients()
    {
        // Add light sugar
    }

    ...
};

class ChoclateCakeBaker : public CakeBaker {
public:
     Cake Bake(BakingSteps& steps)
     {
         steps.AddLiquieds();
         steps.AddChocolate();      // chocolate instead of fruits
         return builder.getCake();
     }
}

Answer 4

Builder 知道如何执行特定步骤。
总监知道如何使用构建器步骤组装整个东西。

他们一起工作。

我在这种模式中看到的唯一弱点是客户端能够在没有Director的情况下直接调用Builder方法 - 这可能会带来一些问题和不连贯（例如不调用作为整个算法一部分的Init方法）

Answer 5

假设您想做一个没有干原料的蛋糕。你要做的只是在Director中添加一个新方法或者创建另一个Director。这将保护您免受继承复杂性的影响，并使您的代码更加灵活。

Answer 6

我同意你的看法。我认为另一种方法是 CakeBaker 应该有一个 GetCake() 方法，它返回一个蛋糕（Cake 类）和 MakeCake() 方法，算法将在其中运行。这很好，但另一方面，那里有一个负责任的分离。将抽象构建者和特定构建者视为仅蛋糕部件的构建者，将总监视为经理或设计师，其职责是组装和生产蛋糕。

Answer 7

模式的缺点是它们会用技术术语污染我们对业务领域的理解并模糊我们的焦点。

在我看来，蛋糕和制作蛋糕的知识之间存在太多的耦合。这些可以通过在我们的代码中引入具有食谱的蛋糕的想法来解耦（更像是从现实世界借用，按业务领域设计我们的模型）。食谱将包含配料和烘焙步骤（只是步骤名称，不是实际实施，因为食谱不烘焙蛋糕），说明如何制作食谱所描述的蛋糕。我们的面包师将有一个方法 BakeCake(recipe)，以及根据烘焙步骤的一系列较小的方法，例如混合、添加成分等。

请注意，如果您需要为一般厨师建模，而不仅仅是蛋糕面包师，您还需要将烘焙知识与面包师本身脱钩。这可以通过引入厨师拥有技能的想法来完成。