Java多态实现简单工厂模式解耦思路

简单工厂将对象创建逻辑集中到工厂类中，使业务代码只依赖接口而不关心具体实现，从而实现解耦；新增支付方式只需修改工厂类，无需改动业务代码。

为什么简单工厂里不能直接 new 具体类

因为一旦在业务代码里写 new PaymentWechat() 或 new PaymentAlipay()，创建逻辑就和使用逻辑绑死了。后续加新支付方式、换实现、做 mock 测试，都得改业务代码——这不是解耦，是焊死。

简单工厂的核心动作，就是把 new 这个操作收拢到一个单独的类（比如 PaymentFactory）里，用多态向上转型，让调用方只依赖 Payment 接口，不关心背后是谁。

• 工厂方法返回类型必须是接口或父类，比如 Payment create(String type)
• 所有具体实现类（PaymentWechat、PaymentAlipay）都要实现该接口
• 工厂内部用 if-else 或 switch 判断类型，但外部完全看不到这些分支

如何让工厂支持新增类型而不改原有代码

严格来说，标准简单工厂做不到“完全不改”——它的 create() 方法里必然有判断逻辑。但可以控制修改范围：只动工厂类，不动业务类、不改接口、不碰已有实现类。

常见错误是把类型字符串硬编码在业务侧：factory.create("wechat")，结果哪天拼错成 "weichat"，运行时报 NullPointerException 都不知道哪来的。更稳妥的是用枚举限定合法类型。

• 定义 enum PaymentType { WECHAT, ALIPAY, UNIONPAY }
• 工厂方法签名改为 Payment create(PaymentType type)，避免字符串误传
• 新增类型时，只需扩展枚举 + 在工厂 switch 中加一个 case + 写新实现类
• 不要在工厂里用 Class.forName().newInstance()——反射绕过编译检查，出错晚、难调试

多态在这里到底起了什么作用

不是为了炫技，而是让“调用方不感知实现变化”。业务代码拿到的是 Payment 类型的引用，调用 pay() 时，JVM 根据实际对象类型自动分派到对应实现——这个动态绑定过程，就是多态在扛事。

如果工厂返回的是具体类型（比如 PaymentWechat），那业务代码变量声明也得跟着变，一加新支付方式就得批量改声明、改调用，彻底失去弹性。

• 接口定义行为契约：void pay(BigDecimal amount)
• 每个实现类覆盖自己的逻辑，但签名不变
• 工厂返回 Payment，业务代码只调 payment.pay(...)，连 instanceof 都不该出现
• 测试时可直接传入 mock 实现，无需启动真实支付通道

简单工厂和策略模式容易混淆的边界

它们长得像，但目的不同：简单工厂专注“怎么造出来”，策略模式专注“造出来后怎么用”。你可能在一个项目里同时用两者——工厂负责生成策略实例，策略接口本身由多态驱动。

典型踩坑是把工厂类写成策略上下文：比如在 PaymentContext 里既缓存实例又做类型路由。这会让职责混乱，一旦要支持同一类型多个配置（如两个不同的微信商户号），就卡住。

• 工厂只做一件事：根据输入，返回一个符合接口的新对象
• 策略上下文（如 PaymentExecutor）负责持有、执行、切换策略，不参与创建
• 如果创建逻辑变复杂（比如需依赖配置中心、需初始化连接池），简单工厂应升级为工厂方法或抽象工厂，而不是硬塞更多 if

多态是基础，但别指望靠它掩盖设计失衡。工厂类开始出现“创建前校验参数”“创建后设置回调”“缓存单例实例”这些逻辑时，就该停下来想想：它是不是已经不只是“简单”工厂了。