为什么工厂方法是一个类模式，而一个抽象工厂是一个对象模式？

Question

来自GOF书：

  

类模式处理类及其子类之间的关系。这些关系是通过继承建立的，   所以它们在编译时是静态修复的。 对象模式交易   具有对象关系，可以在运行时更改   更有活力。几乎所有模式都在某种程度上使用继承。   所以标记为“类模式”的唯一模式是那些关注的模式   阶级关系。

为什么工厂方法是一个类模式，而抽象工厂是一个对象模式，因为它们似乎是非常相似的模式？

感谢。

Answer 1

GOF书中说

  

意图

     

定义用于创建对象的接口，但让子类决定实例化哪个类。

这是什么意思？我们来看看这本书所展示的例子。

在示例中，框架定义了Application接口以允许其他人实现它。这意味着我可以实现例如像这样的MyApplication或MyOtherApplication：

public class MyApplication extends Application {
    protected Document createDocument() {
        return new MyDocument();
    }
}


public class MyOtherApplication extends Application {
    protected Document createDocument() {
        return new MyOtherDocument();
    }
}

当框架启动时，它可能会根据它在类路径中找到的内容选择其中一个实现。

但这意味着在框架实例化MyApplication或MyOtherApplication之后，文档的创建方式就是修复。 Application实例不能再在运行时更改文档的创建方式。您可以使用没有setter或其他任何来更改Document的创建方式。因此它也被称为虚拟构造函数，因此它是类模式。

抽象工厂

与工厂方法相比，抽象工厂可以在运行时更改，从而改变它创建的对象的方式。这就是为什么他们说这是对象模式。

抽象工厂也负责创建

  

......相关或依赖对象的家族......

这也是工厂方法的一个区别。虚拟构造函数。

Answer 2

工厂方法和抽象工厂的意图相似，但在实施方面却大不相同（你甚至可以说相反）。换句话说，这些模式代表了解决同一问题的不同方式（实例化）。

GoF说，

  

我们按两个标准对设计模式进行分类。第一个标准，   称为目的，反映了模式的作用。

因为他们的意图相似（即他们有相同的目的），这两种模式都被归类为创造。

GoF继续说，

  

第二个标准，称为范围，指定模式是否适用   主要是对类或对象。

这引入了OP的引用，其中每个类都定义了类和对象范围。因为Factory Method的实现侧重于继承（类关系），而Abstract Factory的实现侧重于组合（对象关系），所以这两种模式被分类在相反的范围内。

这两种模式的定义和实现可以在很多其他SO线程中找到，所以我在此不再赘述。我还在这两种模式elsewhere中提到了构成与继承问题。

Answer 3

工厂模式可能更适合放在自己的类别中。但是对象/类划分背后的逻辑可能非常简单。最小形式的工厂方法是静态的（不可配置），就像类一样。但是抽象工厂结果（它们产生的对象）类依赖于一些输入数据，并且因为它是动态效果，所以它应该被放入对象模式类别中。