design-patterns - 生成器设计模式 : Why do we need a 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.

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

模式说要这样做。对于每个产品，我们创建一个具体的构建器类，其中包含上述每个步骤的实现。所有这些类都派生自一个抽象构建器基类，它本质上是一个接口(interface)。因此，例如，我们将有一个抽象基类 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 .此类将接受(来自客户端)一个具体的构建器对象并使用其方法来创建和返回所需的产品。

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

Answer 1

构建器模式的核心部分涉及抽象构建器及其子类(具体构建器)。根据GoF's Design Patterns ，director 只是“在需要构建产品的一部分时通知构建器”，这可以由客户完美地完成。

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

此外，在 Effective Java和 Creating and Destroying Java Objects , Joshua Bloch 建议使用 builder 模式，并且他不包括导演。