多态让工厂回归只创建、不判断的本职，通过注册表替代硬编码分支、返回接口、配合依赖注入实现解耦。
多态本身不“打碎”工厂，而是让工厂回归本职——只管创建，不管判断。所谓“打碎工厂”，其实是把原本塞在工厂里的冗长 if-else 分支逻辑，通过多态机制转移到运行时动态分派，从而让工厂变薄、变傻、变稳定。
识别并剥离工厂中的条件判断
原始工厂常是这样：
- 接收一个字符串或枚举（如
"alipay"、"wechat"） - 内部用
if-else或switch匹配类型 - 每个分支里
new对应的具体类
这种写法导致每次新增一种类型，就必须打开工厂改代码。真正该“打碎”的，是这段判断逻辑——把它从工厂中抽离出去，交给配置或容器管理。
用注册表替代硬编码分支
把“类型 → 实现类”的映射关系外置，工厂只做查表和实例化：
- 定义
Map<string class extends paymenthandler>></string>，启动时加载所有已知处理器 - 工厂的
create(String type)方法只负责根据 key 取 class、反射或构造器创建实例 - 新增支付方式？只需加一个实现类 + 在配置或静态块中注册一次，工厂代码零改动
让工厂返回接口，彻底切断调用方与具体类的联系
关键不是工厂怎么建，而是它返回什么：
- 工厂方法签名必须是
PaymentHandler create(String type)，不是AlipayHandler create(...) - 业务代码拿到的是接口引用，调用
handler.handle(data)时，JVM 自动绑定到实际子类 - 禁止在业务层出现
instanceof、强制转型或基于类型的if判断——那是多态没落地成功的信号
配合依赖注入，让工厂也“隐形”
工厂本身不该被业务类 new 出来，更不该被硬编码调用：
- 在 Spring 中，用
@Bean声明工厂，业务类通过构造器注入PaymentFactory接口 - 或者直接注入策略集合：
List<paymenthandler></paymenthandler>，再按需筛选（配合@Qualifier或自定义注解） - 这样连工厂类名都对业务层不可见，真正实现“创建”与“使用”的双重解耦
