为什么要使用构建器模式？

Question

在大多数教程中(Judith Bishops的书,或者这里),我看到类似于下面的例子.

如果构建器模式意味着在Director类中创建方法Construct,它执行一组Builder子操作...

class Director {
  public static void Construct(Builder builder) {
    builder.BuildPartA();
    builder.BuildPartB();
    ...
  }
}

abstract class Builder {
  public abstract void BuildPartA();
  public abstract void BuildPartB();
  ...
}

class Builder1 : Builder { ... }
class Builder2 : Builder { ... }

void Main() {
  Builder1 b1 = new Builder1();
  Builder2 b2 = new Builder2();
  Director.Construct(b1);
  Director.Construct(b2);
}

...为什么我们不将Construct方法移动到Builder类？

class Builder {
  public virtual void BuildPartA();
  public virtual void BuildPartB();
  public void Construct() {
    BuildPartA();
    BuildPartB();
    ...
  }
  ...
}

class Builder1 : Builder { ... }
class Builder2 : Builder { ... }

void Main() {
  Builder1 b1 = new Builder1();
  Builder2 b2 = new Builder2();
  b1.Construct();
  b2.Construct();
}

请给我看一些构建模式真正有用的示例.

Answer 1

目录应该知道组装不同组件的正确顺序以构造对象.我相信它只是将了解构造这些对象的顺序或方法与基础Builder类(它只是一个基类)分开.如果将构造移动到Builder基础中,它将类似于模板方法模式.

最好有一个知道如何组装组件的独立控制器,因为即使构造组件的"配方"发生变化,基类也不需要改变.例如,假设需要通过按特定顺序执行3个步骤来构建某类组件:

1. 步骤A.
2. 步骤B.
3. 步骤C.

让我们说在某个时候,另一个组件被添加到系列中,可以使用相同的步骤但以不同的顺序构建:

1. 步骤A.
2. 步骤C.
3. 步骤B.

在这种情况下,如果序列的逻辑在Director中与基类Builder分开,则可以继承新的Director并使用它来构造.如果逻辑位于基础构建器中,基类(可能是单独的库或JAR的一部分或C++中的头文件),则可能需要重新编译具体类或至少运送新的JAR.

我相信分离这样一个问题有更多的好处.