工厂方法模式：如何解决生成对象时的不确定性？

今天我们接着来看另外一个工厂模式：工厂方法模式**（Factory Method Pattern）**。

工厂方法模式就是我们俗称的工厂模式，和抽象工厂模式很类似，但工厂方法模式因为只围绕着一类接口来进行对象的创建与使用，使用场景更简单和单一，在实际的项目中使用频率反而比抽象工厂模式更高。

一、模式原理分析

工厂方法模式的原始定义是：定义一个创建对象的接口，但让实现这个接口的类来决定实例化哪个类。

工厂方法模式的目的很简单，就是封装对象创建的过程，提升创建对象方法的可复用性。

我们直接来看看工厂方法模式的 UML 图：

从图中可以看出，工厂方法模式包含三个关键角色：

• 抽象接口（也叫抽象产品）；

• 核心工厂；

• 具体产品（也可以是具体工厂）。

其中，核心工厂通常作为父类负责定义创建对象的抽象接口以及使用哪些具体产品，具体产品可以是一个具体的类，也可以是一个具体工厂类，负责生成具体的对象实例。于是，工厂方法模式便将对象的实例化操作延迟到了具体产品子类中去完成。

不同于抽象工厂模式，工厂方法模式侧重于直接对具体产品的实现进行封装和调用，通过统一的接口定义来约束程序的对外行为。换句话说，用户通过使用核心工厂来获得具体实例对象，再通过对象的统一接口来使用对象功能。

工厂方法模式对应 UML 图的代码实现如下：

//抽象产品
public interface IProduct {
   
    void apply();
}
//核心工厂类
public class ProductFactory {
   
    public static IProduct getProduct(String name