Design patterns 工厂法什么时候比简单工厂好，反之亦然？

通过阅读Head First Design Patterns一书，我找到了自己的方法

我相信我理解简单工厂和工厂方法，但我很难看到工厂方法比简单工厂有什么优势

如果对象A使用简单工厂创建其B对象，则客户端可以这样创建：

A a = new A(new BFactory());

A a = new ConcreteA(); // ConcreteA contains a method for instantiating 
                       // the same Bs that the BFactory above creates, with 
                       // the method hardwired into the subclass of A, ConcreteA.

然而，如果对象使用工厂方法，客户端可以这样创建它：

A a = new A(new BFactory());

A a = new ConcreteA(); // ConcreteA contains a method for instantiating 
                       // the same Bs that the BFactory above creates, with 
                       // the method hardwired into the subclass of A, ConcreteA.

因此，在简单工厂的情况下，客户机用一个B工厂组成A，而使用工厂方法，客户机为它想要的B类型选择合适的子类

他们之间似乎真的没有太多选择。您必须选择要使用哪个BFactory编写A，或者必须选择A的正确子类来生成Bs

在什么情况下一个比另一个好

谢谢大家

编辑：让我感到困惑的是，头先叙述中给出的解释，他们从一个简单的工厂过渡到另一个工厂，他们说（第119页）“特许经营使用的是你的[简单]这家工厂生产比萨饼，但在剩下的过程中，他们开始采用自己的土生土长的程序：他们烤的东西会有点不同……”他们有一张厨师的照片，他显然对他的比萨饼做了一些恶心的事情

但是，使用简单的工厂并不能让客户机访问bake（）方法或该过程的任何其他部分。如果有任何问题，使用工厂方法是没有帮助的

---

因此，在我看来，Head First暗示的在简单工厂上使用工厂方法的原因是假的。

比较第117页和第131页的UML图。关键是，这个简单的工厂决定如何为比萨饼店烘焙比萨饼。工厂法允许混凝土比萨饼工厂决定如何烘烤比萨饼。工厂是关于管理依赖关系的。使用构造函数，您必须决定实例化哪个类。使用简单工厂，您可以让具体类决定实例化哪个类。使用工厂方法，您可以让任何类（可以）决定实例化哪个类。使用抽象工厂，您可以让任何类（可以）决定实例化哪个类，而不管您想要创建什么样的实例。控制反转就是利用你所得到的，因为这个决定是在神圣存在创造你的时候做出的

---

我个人的观点是，GoF最初的设计模式书，虽然在解释方面不太好，但有更多的现实世界的例子

分析不同角色的差异：A的用户和A的提供者。这些模式对这些角色有不同的含义，随着时间的推移，这些意义重大

就

A myA = new SomeConcreteA()

A myA = new A(myBFactory())

A的客户甚至不知道Bs的存在。特定混凝土a的选择可能会受到某些文档的影响，这些文档使用特定的B或某个族的某些完全其他的特性。A的供应商负责创造混凝土A的所有味道，因此当B的种类发生变化时，他们可能有工作要做

就

A myA = new SomeConcreteA()

A myA = new A(myBFactory())

客户现在需要了解Bs及其工厂，并完全控制使用哪个工厂。提供者hs赋予客户机更多的责任，我们可能增加了耦合——客户机代码现在明确地依赖于至少一个以上的类。当新类型的B出现时，A的提供者没有工作要做

---

请注意，我们正在注入B工厂，因此在编写客户机单元测试时，我们现在可以更容易地为B提供模拟，因此测试客户机往往更容易。一般来说，我发现出于这个原因，我更频繁地使用这种注入方法。

您是正确的，从简单工厂到工厂方法的所有变化似乎都是在简单工厂中，工厂通过构造函数传入，我们使用它来创建对象。在工厂方法中，现在调用抽象工厂类中的抽象方法；但这是强大的。因为这个方法是抽象的，所以它必须在我们的子类中实现，这就是我们想要的。我们的子类可以实现它们自己的变体，但某些行为仍然由抽象类强制执行。更强大的是，通过添加继承自抽象基类的新类，我们可以在不修改原始代码的情况下扩展工厂的数量

我明白你的意思，对此也感到困惑。我认为他们的观点是，某些行为可以通过在（抽象）基类中实现来在子类中强制执行。