接口在工厂模式中作为返回类型，是为了让工厂方法不绑定具体实现，只承诺返回符合某组行为规范的对象；工厂方法返回接口而非具体类，调用方仅依赖接口编程，隐藏实现细节，支持灵活替换与扩展，新增实现时客户端代码零改动，便于单元测试和抽象工厂统一管理产品族。

接口在工厂模式中作为返回类型，是为了让工厂方法不绑定具体实现，只承诺返回符合某组行为规范的对象。

工厂方法返回接口，而不是具体类

工厂类的创建方法（比如 createProduct()）声明返回一个接口类型，调用方拿到的是该接口的引用，完全不知道背后是哪个实现类。这样既隐藏了实现细节，又支持后续替换或扩展实现。

• 定义产品接口，如 PaymentProcessor，声明 process() 方法
• 提供多个实现类，如 AlipayProcessor、WechatProcessor
• 工厂类中方法返回 PaymentProcessor，内部根据条件 new 对应实现类并返回

客户端只依赖接口，不关心谁来实现

调用工厂的代码只需面向接口编程。例如：PaymentProcessor p = factory.create("alipay"); p.process(); —— 它不需要 import 任何具体处理器类，也不需要 if-else 判断类型，所有耦合都集中在工厂内部。

JavaStoryDevelop

你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在

下载

• 新增支付方式时，只需加实现类 + 修改工厂分支逻辑，客户端代码零改动
• 单元测试可轻松注入 mock 实现，因为依赖的是接口而非具体类
• 避免客户端因使用 instanceof 或强转而破坏开闭原则

结合抽象工厂时，接口作为产品族统一入口

当系统有多个产品等级（如支付 + 通知），抽象工厂返回一组相关接口（PaymentProcessor 和 NotificationSender），每个具体工厂负责返回配套的一组实现。接口在这里充当“契约桥梁”，确保产品之间协作一致。

立即学习“Java免费学习笔记（深入）”；

• 例如：国内工厂返回 AlipayProcessor + SmsSender，海外工厂返回 PayPalProcessor + EmailSender
• 上层业务模块接收接口组合，无需感知地域差异
• 接口名清晰表达能力边界，比如 Logger 不该有 sendEmail() 方法

注意：接口不能 new，工厂必须返回其实现实例

工厂方法体内不能直接 return new PaymentProcessor()（编译报错），必须返回实现了该接口的某个类的实例。常见写法是用 if/switch 或 Map 查找后 new 出具体对象，或通过反射、SPI 加载。

• 推荐用枚举或配置驱动选择实现类，减少硬编码分支
• 避免在工厂里做复杂逻辑，可委托给策略类或 Spring Bean 容器管理
• 如果所有实现都无状态，也可考虑用静态工厂方法 + public static final 接口实现常量