design-patterns - 抽象工厂和构建器之间的区别？

Question

抱歉又问了。我在网上搜索过，但无法理解，因此我必须放在这里。这里是我自己研究的。我从 head first 设计模式开始学习。
抽象工厂模式:

根据我研究的差异，建筑商在某些方面感觉它是一家工厂，但是
大多数情况下，它只创建一种类型。
那么我可以说上图中的 NYStore 是构建器，因为它将披萨对象返回给客户端吗？
我对么？请根据上面的例子给出你的答案，这可能有助于我学习它。

Answer 1

有趣的。我建议对图表进行一些更改，使其符合 GoF 定义的经典 Builder 模式。

最大的不同在于，在构建器模式中，“主管”不知道构建器的细节。因此，与其有一个名为 NyPizzaStore 的类和一个名为 createPizza() 的方法(显然)高度调整以创建纽约风格的比萨饼，您可能会拥有一个类调用 PizzaChef ，它接受一个类的实例，该类自定义如何披萨做好了。 (对于此示例/类比，让我们将 rename PizzaIngerdientFactory 重命名为 Recipe，以便我们可以稍微不同地对待它)。所以这给了你 PizzaChef.createPizza(Recipe r) 。 PizzaChef 类不需要担心蛤蜊是新鲜的还是冷冻的，他只需依次调用每个构建器并创建所需的比萨饼。这是差异的关键……只有一个 PizzaChef，他不知道食谱的细节(子类)。

这样做的一个很好的副作用是，您可以轻松地混合和匹配构成 Recipe 类的构建器，这样您就可以使用与 NYStyle 相同的所有成分构建器来创建 NewHavenStyle 比萨饼，但替换为 BrickFiredThinCrust。更可定制。 Recipe 成为构建器实例的持有者。

当然，现在我饿了:)

注意不要混淆模式的名称(这是一种可重用的技术，几乎总是涉及多个对象/参与者/角色)和模式中特定角色的名称。此外，模式通常建立在彼此之上并且有很多重叠。

在 Builder 模式 中，有一个 Director 对象，它有一个 createSomething() 方法(不是调用它)。该方法将以一种非常公式化的方式调用一个或多个零件构建器。客户端有对 Director 的引用，并传入构建器。客户直接或间接地影响构建的内容。 Director 不需要是任何东西的子类，它可以是一个简单的密封类。 PizzaChef 不是客户而是导演。它不会从任何东西继承，也不会被继承。在这种情况下，客户端可能类似于 Customer 类。

现在，正如 Abstract Factory 模式建立在一组 Factory Methods 上(来自该名称的模式)，您可以让 Builder 模式使用 Abstract Factory 。您可以将构建器作为 AbstractFactory 传递给 Director。在这种情况下，Recipe 将是您的 AbstractFactory，而 NyStyleRecipe 将继承 Recipe 并提供 PizzaChef 类将用于创建比萨饼的构建器方法。在这个特定的实现中，Directpr 模式的 Builder 确实是原始图中描述的客户端。

但正如我之前试图提到的，这并不是实现 Builder 模式的唯一必要条件，我认为它增加了 Builder 旨在克服的限制。我会改用可组合的 Recipe 类，因为这样您就可以更轻松地混合搭配成分。薄皮和纽约式披萨之间没有真正的联系。纽黑文风格也采用薄款。

Recipe newyorkStyle = new Recipe(
   new ThinCrustBuilder(), 
   new RedSauceBuilder(), 
   new FreshClamsBuilder(), 
   new ElectricOvenBuilder());

Recipe newhavenStyle = new Recipe(
   new ThinCrustBuilder(), 
   new WhiteSauceBuilder(), 
   new FreshClamsBuilder(), 
   new BrickOvenBuilder());

PizzaChef chef = new PizzaChef ();

nyPizza = checf.createPizza(newyorkStyle);

nhPizza = checf.createPizza(newhavenStyle);

请注意，我使用了可组合的构建器来重复使用薄 shell 和新鲜的蛤蜊。使用 Abstract Factory 这不会那么容易

我希望能进一步澄清差异!