c# - 为什么要使用 builder 模式？

Question

在大多数教程(Judith Bishops 的书，或 here )中，我看到了类似于下面的示例。

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

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 并使用它来构造。如果逻辑在基类 Builder 中，基类可能是单独的库或 JAR 的一部分，或者在 C++ 的情况下是头文件，它可能需要重新编译具体类或至少运送一个新的 JAR。

我确信将这样的问题分开会有更多的好处。