多态是工厂方法模式的底层核心机制而非附加特性，它通过父类引用指向子类对象实现运行时动态绑定，支撑客户端仅依赖抽象工厂和抽象产品，使新增类型无需修改原有代码，真正实现开闭原则。
多态是工厂方法模式得以成立和发挥价值的底层支撑，不是附加特性，而是实现逻辑的核心机制。
多态为工厂方法提供运行时动态绑定能力
工厂方法模式要求客户端只依赖抽象工厂和抽象产品，不感知具体类型。这背后依赖的就是多态的“父类引用指向子类对象”机制：
- 抽象工厂（Creator）声明 abstract Product factoryMethod()，返回的是抽象产品类型
- 具体工厂（如 ConcreteCreatorA）覆写该方法，返回 ConcreteProductA 实例，但类型仍被声明为 Product
- 客户端调用时拿到的是 Product 引用，却能执行 ConcreteProductA 中重写的业务方法——这正是多态的动态分派在起作用
三个必要条件在模式中一一对应
多态的三大前提，在工厂方法结构中自然落地：
- 继承关系：ConcreteCreator 继承 Creator；ConcreteProduct 实现或继承 Product
-
方法重写：每个具体工厂必须重写 factoryMethod()；每个具体产品通常重写抽象产品定义的业务方法（如
operate()、render()） - 父类引用指向子类对象：客户端持有的是 Creator 类型变量，实际运行时指向 ConcreteCreator 实例；调用 factoryMethod() 得到的是 Product 类型引用，背后是 ConcreteProduct 实例
多态让扩展真正“开闭”
没有多态，工厂方法就退化为条件判断或硬编码。多态使新增产品无需修改原有代码：
- 添加新类型产品（如新增
CloudStorage）只需实现 Product 接口 - 添加对应工厂（如
CloudStorageFactory）只需继承 Creator 并覆写 factoryMethod() - 客户端代码完全不变，仍通过 Creator.create() 获取 Product，运行时自动绑定新实现
典型误用：忽略多态导致耦合回流
常见错误会破坏多态链条，使模式失效：
- 在客户端对 Product 引用做
instanceof判断并强转——绕过抽象层，暴露具体类型 - 抽象工厂中提供多个不同返回类型的工厂方法（如
createA(): A和createB(): B）——违背单一抽象接口原则，失去多态统一性 - 具体工厂内部 new 具体产品后，再包装成其他非 Product 类型返回——切断多态链路
工厂方法模式不是“用了多态”，而是“靠多态活着”。它把多态从语法现象升华为架构契约，让类型选择从编译期决策移至运行期配置，这才是可扩展性的真正来源。
