Java 我们什么时候应该使用工厂方法模式？（代替作文）

根据

GOF

手册，

工厂方法模式

定义用于创建对象的接口，但让子类决定实例化哪个类。工厂方法允许类将实例化延迟到子类

图案结构

工厂需要一个对象（其具体类未知或其具体类可能会根据不同的应用程序类型而变化）来执行任务

因为它不知道实例化哪个类，所以为所需的对象类型设置了一个标准约定，该约定被放在一个接口中

基本工厂类声明了一个

抽象

方法，以返回上述定义的

接口

类型的对象。 它让子类决定并提供对象创建的实现

为了完成任务，它需要一个对象，只需调用

abstract

方法即可获取该对象

问题偏好组合而非继承。 上面的工厂方法使用继承来获得具体的产品。子类还需要实现createProduct，它将创建并返回ConcreteProduct。如果从工厂类中删除了抽象方法（使工厂类成为非抽象类），则不必对工厂类进行子类化。现在工厂类可以由新类组成，具体的产品对象可以注入其中，如下例所示

为了在工厂方法模式定义的场景中实现目的，为什么不按以下方式使用正常多态性？我知道工厂方法模式还有一些我所缺少的东西，但我认为下面的方法可以解决相同场景中的相同问题，比工厂方法更好。与下面的方法相比，

工厂方法

有什么优势

public abstract class Factory {
    private void performCriticalJob(IProduct product){
        product.serve();
        //some code
    }
    public void executeJob(IProduct product){
        //some code
        performCriticalJob(product);
        //some more code
    }
}

现在，用户可以直接将实现IPProduct的具体类的对象提供给

executeJob

，而不是要求用户创建子工厂类并通过实现createProduct方法返回产品的具体对象

[编辑]感谢您的回答和评论，但与我在评论和回答中表达的想法相同，这也带来了一些混乱。我研究了

GOF

工厂方法模式。它使用了一个框架示例，用于创建各种类型文档的应用程序。我的问题是在这项研究之后引起的怀疑

---

网站和博客只是作者对模式理解的反映，他/她可能读过也可能没有读过，理解了模式的实际意图。理解课程不是主要目标。设计模式的研究应该考虑到什么样的场景和什么样的问题，哪一个是遵循好的OOP原则的最佳解决方案（或者至少违反了这些原则，并且有很好的理由这样做）。最好的解决方案就是任何

设计模式所解释的解决方案
GOF
是一本标准书，对其进行了很好的解释。但仍然存在一些空白或疑问，这是这个问题的主要原因。
请再次阅读您提供的定义：

为创建对象定义一个接口，但让子类决定实例化哪个类。工厂方法允许类将实例化延迟到子类

这与你的第一句话有点矛盾：

工厂需要一个对象（其具体类未知或其具体类可能会根据不同的应用程序类型而变化）来执行任务

工厂的目的是创建对象，而不是执行任务

事实上，如果它将执行一项任务，那么它只能为您创建对象。
从工厂获得对象后，可以执行关键工作

关于支持组合而不是继承，工厂方法也可以为您组合对象并返回对象组合

工厂模式有很多很好的例子，例如和

编辑-关于GoF
应用程序
示例

应用程序的GoF示例
对
工厂方法
使用
模板方法
。
应用程序
定义了工厂方法及其周围的一些操作，但是
应用程序
的子类决定了创建哪个
文档

您建议，不要使用工厂方法。相反，在其他地方创建
文档
，并“注入”到
应用程序
（也称为依赖项注入）。
您尚未描述将在何处创建
文档
（它可能仍然是一个工厂）。

现在，
应用程序
子类对创建
文档
没有任何控制权。这完全改变了系统的行为和设计

这并不意味着它的好坏，它只是一种不同的方法。

在实际场景中，您必须仔细检查手头的问题，并决定哪种设计最适合

我知道工厂方法模式还有一些我所缺少的东西，但是通过对继承的喜爱，我找到了下面的方法，在相同的场景中解决相同的问题

当使用Factory方法模式而不是问题中所示的简单的旧组合时，您会获得一些优势：

1。关注点分离和开闭原则：为每个相关对象组创建一个工厂子类。这个工厂子类只负责创建那些属于某个特定产品的产品
public abstract class Factory {
    private void performCriticalJob(IProduct product){
        product.serve();
        //some code
    }
    public void executeJob(IProduct product){
        //some code
        performCriticalJob(product);
        //some more code
    }
}