Question

在大多数教程中（Judith Bishops的书，或here），我看到的例子类似于下面的例子。

如果构建器模式意味着在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个步骤来构建某类组件：

步骤A
步骤B
步骤C

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

步骤A
步骤C
步骤B

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

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

Answer 2

观看此视频： http://www.johnlindquist.com/search/label/builder%20pattern

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

2 个答案: