工厂方法模式通过抽象工厂接口和具体工厂子类创建对象，将实例化决策延迟到子类，客户端仅依赖抽象产品与抽象工厂；其核心角色包括抽象产品、具体产品、抽象工厂、具体工厂，典型流程为定义接口→实现类→工厂接口→具体工厂→客户端调用；相比直接new，它解耦客户端与具体类、支持开闭原则、集中管理创建逻辑；实操中需确保工厂方法返回抽象类型、工厂职责单一、参数宜传入构造器、工厂应无状态。
工厂方法模式不直接 new 具体类，而是通过抽象工厂接口 + 具体工厂子类来创建对象。核心是把“创建哪个实例”的决定权交给子类，客户端只依赖抽象产品和抽象工厂。
关键角色与结构
需要四类组件协同工作：
-
抽象产品（Product）：定义统一接口或抽象类，比如
Burger接口 -
具体产品（ConcreteProduct）：实现抽象产品的类，如
BeefBurger、ChickenBurger -
抽象工厂（Creator）：声明工厂方法
create()，返回抽象产品类型 -
具体工厂（ConcreteCreator）：每个子类重写
create()，返回对应的具体产品实例
创建对象的典型流程
以生成不同口味汉堡为例：
- 先定义
Burger接口和两个实现类BeefBurger、ChickenBurger - 定义
BurgerFactory接口，含create()方法 - 写出
BeefFactory和ChickenFactory，各自在create()中return new BeefBurger()或new ChickenBurger() - 客户端代码写成：
BurgerFactory factory = new BeefFactory(); Burger burger = factory.create();
为什么这样创建更合理
相比直接 new BeefBurger()，这种方式带来三个实际好处：
- 客户端不再硬编码具体类名，切换口味只需换工厂实例，不改调用逻辑
- 新增一种汉堡（比如
VeggieBurger），只需加一个新实现类 + 一个新工厂类，原代码完全不动 - 所有创建逻辑集中在工厂子类中，初始化参数、资源加载、日志记录等可统一处理
注意几个实操细节
避免踩坑的关键点：
- 工厂方法必须返回抽象类型（如
Burger），不能返回具体类（如BeefBurger） - 具体工厂类应保持单一职责，一个工厂只创建一种产品，不要在
create()里写 if-else - 如果创建过程需传参（如口味等级、配置项），建议把参数传入工厂构造器，而非塞进
create()方法签名 - 不推荐让抽象工厂带状态，多数场景下工厂实例本身应是无状态的，便于复用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
