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

通过Head First Design Patterns书籍工作。工厂方法何时比简单工厂更好，反之亦然？

我相信我理解简单工厂和工厂方法，但是我很难看到工厂方法对简单工厂有什么优点。

如果对象A使用一个简单的工厂来创建其乙对象，那么客户端可以这样创建：

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的适当子类。

他们之间似乎没有多少选择。要么你必须选择你想要编写的BFactory，或者你必须选择A的正确子类来为你提供Bs。

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

谢谢大家！

编辑：增加一点混乱海事组织是在首脑叙述中给出的解释，他们从简单的工厂过渡到工厂方法，通过说（第119页）“特许经营企业正在使用您的[简单]工厂创建比萨饼，但开始采用他们自己的本土程序进行其余的过程：他们会烘烤一些不同的东西。“他们有一张厨师的照片，显然他做了一些令他厌恶的比萨饼。

但是没有关于使用一个简单的工厂，让客户访问bake（）方法或过程的任何其他部分。而且没有关于使用工厂方法的问题，如果它有任何问题，这些方法都会有所帮助。

所以看起来我喜欢它的原因深入浅出意味着使用一个工厂方法在一个简单的工厂是假的..

来源

2010-06-17 Jeremy

我明白你的观点，也被这个困惑了。我认为他们的观点是某些行为可以通过在（抽象）基类中实现而在子类中强制执行。 – 2010-06-28 19:40:40

在117页和131点是比较UML图，简单厂决定如何为PizzaStore烤比萨饼。工厂方法允许混凝土PizzaFactory决定如何烘烤披萨。工厂是关于管理依赖关系的。使用构造函数，你必须决定实例化哪个类。使用简单的工厂，你可以让具体的类来决定实例化哪个类。使用Factory方法，你让任何类（可以）决定实例化哪个类。使用抽象工厂，您可以让任何类（可以）决定要实例化哪个类，而不管您想要创建什么类型的实例。控制的倒置正在使用你得到的东西，因为决定是在神圣的存在创造你时做出的。

我的个人意见是，GoF的原创设计模式书虽然不擅长解释，但有更多的现实世界的例子。

来源

2010-06-22 20:48:07

分析不同角色的差异：A的用户和A的提供者。这些模式对这些角色具有不同的含义，随着时间的推移，这些角色会发生显着变化。

在A的

A myA = new SomeConcreteA()

客户的情况一无所知的事实，甚至烧烤存在。特定混凝土A的选择可能会受到某些文档的影响，这些文档使用特定B或A系列的某些完全其他特征。 A的提供者负责创建具体的A的所有口味，所以当B类变化时他们可能有工作要做。

在

A myA = new A(myBFactory())

的情况下，客户现在需要了解烧烤和他们的工厂，拥有超过使用哪个工厂的完全控制。提供商给予客户更多的责任，而且我们可能已经增加了耦合 - 客户代码现在明确依赖于至少一个类。当新的B出现时，A的提供者没有工作要做。

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

来源

2010-06-24 06:10:43 djna

你说得对，因为从简单工厂到工厂方法的所有变化都是在Simple Factory中工厂通过构造函数传入的，我们用它来创建我们的对象。在Factory Method中，现在调用抽象工厂类中的抽象方法;但这是强大的。由于该方法是抽象的，它必须在我们的子类中实现，这正是我们所期望的。我们的子类可以实现它们自己的变体，但某些行为仍然由我们的抽象类实施。更强大的是，我们可以在不修改原始代码的情况下扩展工厂数量，只需添加从抽象基类继承的新类即可。

来源

2010-06-28 19:51:25

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

回答

相关问题