简单工厂模式非gof标准模式但实用——用独立工厂类封装实例化逻辑，通过接口返回实现多态，调用方仅依赖抽象不耦合具体类，新增类型只需扩展工厂分支，适合产品稳定场景。
简单工厂模式不是 GoF 二十三种设计模式之一，但它是一个非常实用的入门级解耦技巧——核心是用一个“创建者类”把 对象的实例化过程 从使用方抽离出来，借助面向对象的封装、多态和（可选）继承来降低调用方与具体类型之间的耦合。
用封装隐藏创建细节
不直接 new 具体类，而是把 new 的逻辑放进一个独立的工厂类中。调用方只依赖工厂接口或方法签名，完全不知道背后是哪个子类被创建。
- 比如有 PaymentProcessor 接口，以及 AlipayProcessor、WechatProcessor 等实现类
- 写一个 PaymentFactory 类，提供静态方法 create(String type)
- 业务代码里写 PaymentProcessor p = PaymentFactory.create("alipay");，不再出现 new AlipayProcessor()
靠多态统一操作入口
工厂返回的必须是同一类型（接口或抽象类），这样调用方才能用统一方式处理不同实现。
- 工厂方法返回 PaymentProcessor 接口，而不是某个具体实现类
- 后续调用 p.process(order) 时，JVM 自动根据实际对象类型执行对应逻辑
- 新增支付方式（如 PayPalProcessor）只需实现接口 + 修改工厂分支，业务代码零改动
按需引入继承简化扩展
如果创建逻辑较复杂（比如要初始化公共字段、校验参数、加载配置），可以把工厂设计成抽象类，让子类决定具体实例化哪一类。
- 定义抽象工厂 abstract class ProcessorFactory，含模板方法 getProcessor()
- 子类 AlipayFactory extends ProcessorFactory 覆盖抽象方法，返回新实例
- 调用方持有工厂引用（如 ProcessorFactory factory = new AlipayFactory();），再调用 factory.getProcessor()
注意边界：简单工厂不等于万能解耦
它本质是“条件分支 + new”，适合产品种类稳定、创建逻辑不频繁变更的场景。一旦类型太多或规则太动态（比如根据 JSON 配置创建任意组合），就该升级为工厂方法模式或抽象工厂模式。
- 避免在工厂里写超长 if-else；可用 Map 缓存 Class 对象 + 反射（慎用，牺牲可读性）
- 工厂类本身应保持无状态，不要在其中维护业务上下文或共享资源
- 单元测试时，可轻松 Mock 工厂返回值，隔离验证业务逻辑
