工厂方法中的继承模式与抽象工厂模式中的组合

Question

我只是通过工厂方法模式和抽象工厂方法模式的维基页面。

从Head First设计模式，我得到这个

工厂方法模式使用继承，抽象工厂模式使用 组成。抽象工厂模式也可以像Factory Method Pattern一样执行，它使客户端与具体类型分离，但以不同的方式。

在分析wiki示例之后，我实际上找不到示例中的组合。这两种模式都使用继承。

工厂方法模式

抽象工厂模式

这里是我的问题。

1. 工厂方法模式总是只有一个抽象产品继承树不像抽象工厂方法模式？
2. 哪里可以使用或编程方式的组成？如果它只是具有main方法的Client，则Factory Method Pattern也使用Composition。代码片段的例子将清除这个概念。
3. 我对样本草图中的这些模式的解释是否正确？

Answer 1

是的，正如“Fuhrmanator”指出的那样，它看起来是重复的。所提到的问题答案对这两种模式提供了很好的解释。简而言之，GOF设计模式目录会谈到三种与“工厂”术语相关的模式。所有三个都是创作模式。大多数人在使用术语“工厂模式”时使用静态工厂实施。

静态工厂在本质上是

AbstractProduct getProduct(key){ 
    if (key == ...) return new ConcreteProduct1(); 
    ... so on. 
} 

厂方法的一种方法包封的具体类的创建被维持为钩一个抽象方法，以延缓混凝土产品的实例化的方便的方法。当我们在编写业务逻辑的框架编写时，这是非常有用的，但我们不希望假设客户端开发人员将在以后编写的具体类（此逻辑适用于此类）的任何内容。 （未重复的UML图图案的在这里）

抽象工厂模式是工厂方法，在这里我们需要限制其可实例化并使用，但完整的风味变化（其中我们将产品的类型的更一般的情况在整个应用程序生命中不会一直在不同的口味之间进行切换）。

例如抽象ShapeFactory可能创造3种形状，如圆形，正方形和长方形提供接口，而混凝土工厂FilledShapeFactory和HollowShapeFactory将它们必然会填补，这三种形状的空心版本（具体工厂不能自由决定新形状或放下任何形状）。

如果各种形状（产品）因强制更改界面和影响客户端而发生更改，则无法使用此模式。

风味变化的原因可能是由于父母环境，操作系统或任何其他严重影响的参数。