工厂设计模式的核心价值在于用多态性解耦“创建谁”和“怎么用”：工厂返回抽象类型，客户端通过统一接口调用，运行时自动绑定具体子类实现，新增产品无需修改现有代码。
工厂设计模式的核心价值，就在于用多态性把“创建谁”和“怎么用”彻底分开。它不靠硬编码决定实例类型，而是让运行时根据上下文自动选择具体类——这正是解耦的关键。
为什么多态性是工厂模式的底层支撑
没有多态，工厂返回的对象就无法被统一处理。抽象产品（如 Parser 接口或基类）定义了通用行为（如 parse()），而具体产品（JsonParser、XmlParser）各自实现。客户端只依赖抽象产品指针或引用，调用时自动绑定到实际子类方法——这种动态绑定能力，就是多态赋予工厂模式的灵活性。
工厂方法模式如何靠多态实现解耦
工厂方法模式将创建逻辑上移到抽象工厂中，但真正决定返回哪个对象的，是具体工厂的重写方法。比如：
- 抽象工厂声明 createParser()，返回 Parser*（抽象产品指针）
- JsonFactory 重写该方法，返回 new JsonParser()
- XmlFactory 同样重写，返回 new XmlParser()
- 客户端只持有 Factory*，调用 createParser() 后拿到的始终是 Parser*，后续所有操作都基于接口，完全屏蔽了具体类型
避免常见多态误用导致的耦合回流
即使用了工厂，若在客户端代码中做类型判断或强制转换，多态就失效了：
- ❌ 错误：拿到 Parser* 后用 dynamic_cast 转成 JsonParser* 再调用私有方法
- ❌ 错误：工厂返回后，用 if (type == "json") 分支处理不同解析器逻辑
- ✅ 正确：所有差异逻辑封装进具体产品的 parse() 实现中，客户端只调一次统一接口
- ✅ 正确：若需差异化配置，通过构造参数或策略对象注入，而非暴露子类细节
扩展新类型时，多态如何保证零侵入
新增一种 YamlParser，只需三步，不改一行现有业务代码：
- 定义 YamlParser 类，继承 Parser 并实现 parse()
- 定义 YamlFactory，继承 Factory 并重写 createParser() 返回 YamlParser
- 在配置或初始化处，把 Factory* 指针换成 YamlFactory 实例——其余所有调用链保持原样
整个过程依赖的，正是抽象层之上的多态调用机制。类型变化被严格限制在工厂创建点，下游完全无感。
