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

我正在阅读《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 与 B 工厂组合在一起，而使用工厂方法，客户端为它想要的 B 类型选择适当的子类。

他们之间似乎确实没有太多选择。要么您必须选择要与哪个 BFactory 组合 A，要么您必须选择 A 的正确子类来为您提供 B。

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

谢谢大家！

编辑：在我看来，Head First 叙述中给出的解释增加了一点混乱，他们从简单工厂过渡到工厂方法，说（第 119 页）“特许经营店使用你的[简单]工厂来制作披萨，但开始在剩下的过程中采用他们自己的本土程序：他们烘烤的东西有点不同......”他们有一张厨师显然对他的披萨做了一些恶心的事情的照片。

但是，使用简单的工厂并不能让客户端访问 Baker() 方法或该过程的任何其他部分。如果出现任何问题，使用工厂方法没有任何帮助。

所以在我看来，Head First 暗示使用工厂方法而不是简单工厂的原因是假的。

分析不同角色的差异：A 的用户和 A 的提供者。这些模式对这些角色有不同的影响，随着事情随着时间的推移而变化，这些影响很重要。

如果是

A myA = new SomeConcreteA()

A 的客户对 B 的存在一无所知。特定具体 A 的选择可能会受到它使用特定 B 的某些文档或 A 系列的一些完全其他功能的影响。 A 的提供者负责创建具体 A 的所有风格，因此当 B 的种类发生变化时，他们可能需要做一些工作。

如果是

A myA = new A(myBFactory())

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

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