在大多数教程(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();
}
请给我一些构建器模式真正有用的例子。
最佳答案
目录应该知道组装不同组件以构建对象的正确顺序。我相信这只是将了解构造这些对象的顺序或方法的关注与基类 Builder 类(它只是一个基类)分开。如果您将构造移动到 Builder 基础中,它将类似于模板方法模式。
最好有一个单独的主管知道如何组装组件,因为即使构建组件的“配方”发生变化,也不需要更改基类。例如,假设需要通过按特定顺序执行 3 个步骤来构建特定类的组件:
- 步骤A
- 步骤 B
- 步骤C
假设在某个时刻,另一个组件被添加到家族中,可以使用相同的步骤但以不同的顺序构建:
- 步骤A
- 步骤C
- 步骤 B
在这种情况下,如果序列的逻辑在 Director 中分离,而不是在基类 Builder 中,则可以继承一个新的 director 并使用它来构造。如果逻辑在基类 Builder 中,基类可能是单独的库或 JAR 的一部分,或者在 C++ 的情况下是头文件,它可能需要重新编译具体类或至少运送一个新的 JAR。
我确信将这样的问题分开会有更多的好处。
关于c# - 为什么要使用 builder 模式?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/9344716/