建筑师设计模式：为什么我们需要导演？ [英] Builder design pattern: why do we need a Director?
问题描述
我们有一个用于创建产品，即不同类型的对象。在足够高的抽象级别上，所有产品类型的算法是相同的，但是每个产品类型都需要每个算法的抽象步骤的不同实现。例如，我们可能有以下蛋糕烘焙算法：
1.添加液体。
2.混合好
3.加入干成分。
4.混合好
5.将面糊倒入烤盘。
6.烘烤。
7.回蛋糕
不同的蛋糕将需要这些步骤的不同实现，即使用什么液体/干成分，什么速度混合，烘烤多长时间等。
模式说这样做。对于每个产品，我们创建一个具体的构建器类，其中包含以上每个步骤的实现。所有这些类都派生自一个基本的基本类，基本上是一个接口。所以，例如，我们将使用纯虚拟方法 AddLiquid（），$ $ c的抽象基类 CakeBaker $ c> MixLiquids（）等等具体的蛋糕面包师将是具体的子类，例如
class ChocolateCakeBaker：public CakeBaker {
public：
virtual void AddLiquids（）
{
//添加三个鸡蛋和1杯奶油
}
virtual void AddDryIngredients（）
{
//添加2杯面粉，1杯糖，3汤匙可可粉，
// 2条地面巧克力，2茶匙烤粉
}
...
...
};
LemonCitrusCakeBaker 也将是 CakeBaker ，但会在其方法中使用不同的成分和数量。
不同的蛋糕类型将类似于一个抽象的 Cake 基类。
最后，我们有一个类来实现抽象算法。这是导演。在面包店的例子中，我们称之为 ExecutiveBaker 。该类将接受（从客户端）具体的构建器对象，并使用其方法来创建并返回所需的产品。
这是我的问题。为什么我们需要导演与抽象制作者分开？为什么不将它们卷入一个单一的构建器抽象基类，使原始的抽象构建器的公共方法受到保护（具体的子类如前所述）。
Builder模式的核心部分涉及抽象构建器及其子类（具体构建器）。根据 GoF的设计模式，导演只需建立产品的一部分即可建立，这可以完美地完成客户端。
StringBuilder Java API中的一个类是没有相应Director的构建器的例子，通常客户端类引导它。
另外，在有效Java 和创建和销毁Java对象，Joshua Bloch建议使用构建器模式，他不包括一个导演。
Recently I've come across the Builder design pattern. It seems that different authors use "Builder pattern" to refer to different flavours, so let me describe the pattern I'm asking about.
We have an algorithm for creating products, i.e., objects of different types. At a sufficiently high level of abstraction the algorithm is the same for all product types, but each product type requires a different implementation of each of the algorithm's abstract steps. For example, we might have the following cake-baking algorithm:
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.
Different cakes would require different implementations of these steps, i.e., what liquids/dry ingredients to use, what speed to mix at, how long to bake, etc.
The pattern says to do it like so. For each product we create a concrete builder class with an implementation for each of the above steps. All of these classes are derived from an abstract builder base class, which is essentially an interface. So, for example, we will have an abstract base class CakeBaker with pure virtual methods AddLiquid(), MixLiquids(), etc. The concrete cake bakers will be concrete subclasses, e.g.,
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
}
...
...
};
The LemonCitrusCakeBaker would also be a subclass of CakeBaker, but would use different ingredients and quantities in its methods.
The different cake types will similarly be subclasses of an abstract Cake base class.
Finally, we have a class to implement the abstract algorithm. This is the director. In the bakery example we might call it ExecutiveBaker. This class would accept (from the client) a concrete builder object and use its methods in order to create and return the desired product.
Here's my question. Why do we need the director to be separate from the abstract builder? Why not roll them into a single builder abstract base class, making the original abstract builder's public methods protected (and the concrete subclasses override these as before).
The core portion of the Builder pattern concerns the Abstract Builder and its subclasses (concrete builders). According to GoF's Design Patterns, director simply "notifies the builder whenever a part of the product should be built", which can be perfectly done by the client.
The StringBuilder class in the Java API is an example of a builder without the respective director -- typically the client class "directs" it.
Also, in Effective Java and Creating and Destroying Java Objects, Joshua Bloch suggests the use of the builder pattern, and he does not include a director.
这篇关于建筑师设计模式：为什么我们需要导演？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
