接口在工厂模式中作为返回类型，是为了让工厂方法不绑定具体实现，只承诺返回符合某组行为规范的对象；工厂方法返回接口而非具体类，调用方仅依赖接口编程，隐藏实现细节，支持灵活替换与扩展，新增实现时客户端代码零改动，便于单元测试和抽象工厂统一管理产品族。
接口在工厂模式中作为返回类型，是为了让工厂方法不绑定具体实现，只承诺返回符合某组行为规范的对象。
工厂方法返回接口，而不是具体类
工厂类的创建方法（比如 createProduct()）声明返回一个接口类型，调用方拿到的是该接口的引用，完全不知道背后是哪个实现类。这样既隐藏了实现细节，又支持后续替换或扩展实现。
- 定义产品接口，如 PaymentProcessor，声明 process() 方法
- 提供多个实现类，如 AlipayProcessor、WechatProcessor
- 工厂类中方法返回 PaymentProcessor，内部根据条件 new 对应实现类并返回
客户端只依赖接口，不关心谁来实现
调用工厂的代码只需面向接口编程。例如：PaymentProcessor p = factory.create("alipay"); p.process(); —— 它不需要 import 任何具体处理器类，也不需要 if-else 判断类型，所有耦合都集中在工厂内部。
- 新增支付方式时，只需加实现类 + 修改工厂分支逻辑，客户端代码零改动
- 单元测试可轻松注入 mock 实现，因为依赖的是接口而非具体类
- 避免客户端因使用 instanceof 或强转而破坏开闭原则
结合抽象工厂时，接口作为产品族统一入口
当系统有多个产品等级（如支付 + 通知），抽象工厂返回一组相关接口（PaymentProcessor 和 NotificationSender），每个具体工厂负责返回配套的一组实现。接口在这里充当“契约桥梁”，确保产品之间协作一致。
- 例如：国内工厂返回 AlipayProcessor + SmsSender，海外工厂返回 PayPalProcessor + EmailSender
- 上层业务模块接收接口组合，无需感知地域差异
- 接口名清晰表达能力边界，比如 Logger 不该有 sendEmail() 方法
注意：接口不能 new，工厂必须返回其实现实例
工厂方法体内不能直接 return new PaymentProcessor()（编译报错），必须返回实现了该接口的某个类的实例。常见写法是用 if/switch 或 Map 查找后 new 出具体对象，或通过反射、SPI 加载。
- 推荐用枚举或配置驱动选择实现类，减少硬编码分支
- 避免在工厂里做复杂逻辑，可委托给策略类或 Spring Bean 容器管理
- 如果所有实现都无状态，也可考虑用静态工厂方法 + public static final 接口实现常量
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
