工厂模式是否需要工厂方法？

Question

我试图更好地理解工厂设计模式。

我了解该模式通常包括以下内容（总是这样吗？）：

1. Product
2. Concrete Product
3. Creator
4. Concrete Creator

据我了解，工厂方法的重点是 Creator 可能看起来像

Public abstract class Creator
    public void doSomething(){
        Product product= createProduct();
        product.doSomethingElse();
    }

    public abstract Product createProduct();
}

其中createProduct()是 factoryMethod。

然后当 Concrete Creator 创建时，我们覆盖Creator.createProduct() 。

如果这个工厂方法只用于创建产品，那是否意味着我们在技术上可以没有工厂方法，但仍然遵循工厂模式？

例如，而不是

Public ConcreteCreator extends Creator{
  public Product createProduct(){
     return new ConcreteProduct()
  }
}

我们做类似的事情

Public ConcreteCreator extends Creator{
  Product product;
  public ConcreteCreator(){
    this.product = new ConcreteProduct;
  }
}

并将 Creator 更改为类似

Public abstract class Creator
    Product product;
    public void doSomething(){
        this.product.doSomethingElse();
    }
}

看起来这基本上与工厂模式做同样的事情，concreteproduct 仍然负责创建自己的 ConcreteProducts，除了它在构造函数中完成它而不是覆盖工厂方法。

这仅仅是因为将 ConcreteProducts 的创建逻辑从构造函数移到工厂方法中（即仅根据需要创建具体产品等）更清洁吗？ 或者在某些情况下，如果我们只在 ConcreteCreator 的构造函数中创建 ConcreteProducts，我们将无法保持相同的行为？

Answer 1

我认为让您感到困惑的问题是您不应该在 Creator class 中使用 doSomething() 方法。 工厂 class 应负责创建产品，仅此而已。 换句话说，工厂 class 不使用自己的产品。 因此，您的 Creator class 不是抽象工厂。

Answer 2

构造函数无法执行与工厂模式完全相同的事情的一个示例是，当您需要以某种方式共享对象时，例如在 object 池或缓存中。

另一个例子是，如果您希望创建者是可配置的，这样，在某些配置的基础上，一个具体的工厂将被用来代替另一个，而无需以任何方式更改代码。

Answer 3

也许我不太理解，但如果我理解你的问题的核心是为什么要使用方法而不是构造函数来返回具体工厂 object。

我认为它总是取决于具体情况，但是方法比构造函数更灵活。 构造函数的目标是构造 object，并且应该仅限于此。

例如，如果出于某种原因您需要在返回 object、同步或验证之前使用业务逻辑，对我来说使用构造函数没有太大意义（构造函数应该用于构造对象而不是进行操作，这是保留的到方法）。