简单工厂模式非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 工厂返回值，隔离验证业务逻辑