设计模式——理解工厂模式答案

【问题标题】：Design Pattern - Understanding Factory Pattern设计模式——理解工厂模式
【发布时间】：2017-11-01 20:33:21
【问题描述】：

我是设计模式的新手，正在尝试了解它们通常的样子。现在我正在尝试理解工厂模式，我想知道我的示例是否是典型的工厂模式结构：

ShapeFactory 类使用 Shape 类作为依赖项（并且不实例化它们）。 ShapeFactory 必须实例化 Shape 类才能称为工厂吗？这是一个准确的工厂模式图，还是应该将 Shape 类之间的关系改为关联？

【问题讨论】：

【解决方案1】：

您的图表代表了“工厂方法模式”，但是它略微缺少一些重要的类或对象。看起来形状类是 Concrete Creator 类。它没有 Creator 类。

基本上，工厂方法设计模式有四个类和对象：

1) Product : 它定义了工厂方法创建的对象的接口。

2) ConcreteProduct：实现产品接口。

3) Creator：声明工厂方法，返回一个product类型的对象。

4) ConcreteCreator：它重写工厂方法返回一个ConcreteProduct的实例

下图稍作修改，表示完整的工厂方法模式：

【讨论】：

嗯，是的，这似乎更准确地作为工厂模式。你不会知道我的图表是否与其他设计模式更相似？我在考虑策略，但 ShapeFactories 依赖项有点毁了它
对不起，工厂方法是多态的。我看不出这种模式在这里是如何应用的（你在 OP 的设计中添加了很多东西）。充其量只是一个简单的工厂。 stackoverflow.com/a/20859513/1168342
工厂方法通常在类层次结构中实现，尽管它们可能由简单地共享公共接口的类实现。它不是直接多态的。它提供了一种使对象创建多态的方法。工厂方法通常被设计到框架类中，以方便程序员扩展框架的功能。此类扩展通常通过子类化框架类并覆盖工厂方法以返回特定对象来实现。

【解决方案2】：

好的，我想我得到了答案。这可能是一种工厂模式，其方法（例如 CreateCircle()、CreateRectangle 等）在那些实例化类的方法中具有隐藏的依赖关系。

我以为依赖只用于依赖注入，但我猜在方法内实例化类时可能存在依赖。

【讨论】：