工厂方法何时比简单工厂好,反之亦然？

Question

通过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.

因此,在简单工厂的情况下,客户端使用B工厂组成A,而使用工厂方法,客户端为其想要的B类型选择适当的子类.

他们之间似乎没有多少选择.要么你必须选择你想要用哪个BFactory,要么你必须选择A的正确子类来给你Bs.

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

谢谢大家!

编辑:添加一点混乱IMO是Head First叙述中给出的解释,他们从简单的工厂转换到工厂方法,说(第119页)"特许经营权正在使用你的[简单]工厂创造比萨饼,但开始在剩下的过程中采用他们自己的本土程序:他们将事情稍微区别开来......"他们有一张厨师的照片,他显然做了一些令人厌恶的比萨饼.

但是没有什么可以使用一个简单的工厂来让客户访问bake()方法或进程的任何其他部分.并且没有任何关于使用工厂方法如果有任何问题会有所帮助.

所以在我看来,首先暗示在一家简单工厂使用工厂方法的原因是假的.

Answer 1

比较第 117 页和第 131 页的 UML 图。要点是，简单的工厂决定如何为 PizzaStore 烘焙披萨。工厂方法允许具体的 PizzaFactory 决定如何烘烤披萨。工厂是关于管理依赖关系的。使用构造函数，您必须决定要实例化哪个类。使用简单工厂，您可以让具体类决定实例化哪个类。使用工厂方法，您可以让任何类（可以）决定实例化哪个类。使用抽象工厂，您可以让任何类（可以）决定实例化哪个类，无论您想要创建什么类型的实例。控制反转就是利用你所拥有的，因为神圣的存在在创造你的时候就已经做出了决定。

我个人的看法是，GoF 的原创《设计模式》书虽然解释得不太好，但有更多现实世界的例子。