多态是简单工厂和规则引擎动态运行的核心，通过父类/接口引用调用子类实现，实现创建与执行的解耦。
多态是简单工厂和规则引擎能真正“活起来”的关键。它让工厂不绑定具体类型，也让规则不必硬写判断逻辑——同一接口，不同实现，运行时自动切换。
简单工厂里，多态解决“创建谁”的问题
工厂方法返回的是父类或接口类型，比如 Animal animal = PetStore.getAnimal("狗")，实际创建的是 Dog 实例。调用方只认 Animal，完全不知道背后是猫、狗还是猪。
- 新增动物类型，只需加一个子类 + 在工厂里加一行判断，客户端代码零修改
- 字符串参数建议换成枚举，避免拼错导致空指针或逻辑遗漏
- 工厂类通常用静态方法，轻量直接；若需状态管理，可改为单例
规则引擎中，多态支撑“执行哪条规则”
Easy Rules 的 BasicRule 是所有规则的基类，WeatherRule、FizzBuzzRule 都继承它。引擎统一调用 evaluate() 和 execute()，但每个子类内部逻辑完全不同。
- 规则组（如 UnitRuleGroup）本身也继承自抽象基类，可以像单个规则一样被调度
- 条件判断（@Condition）和动作执行（@Action）由子类各自实现，父类只定义流程契约
- 业务人员配置新规则时，系统通过反射加载对应类，靠多态完成实例绑定与方法分派
二者结合：工厂造规则，多态跑规则
典型组合用法是：先用简单工厂根据规则类型码（如 "credit_score_rule"）生成对应的规则子类实例；再把该实例交给规则引擎执行。整个过程客户端只面向 Rule 接口操作。
- 规则新增 = 写一个新子类 + 配置工厂识别码，无需动引擎主流程
- 风控场景中，不同评分模型（Fico、自研、第三方）可共用一套执行框架
- 模板方法常嵌套其中：父类定义 run() 流程（校验→计算→记录），子类只重写核心计算逻辑
落地时容易忽略的关键细节
多态不是加了 extends 或 implements 就自动生效。真正在运行时起作用，依赖几个隐性前提：
- 父类方法必须是非 private、非 static、非 final 的，否则无法被动态覆盖
- 工厂返回的对象引用必须是父类/接口类型，不能是具体子类（如不能写 Dog d = PetStore.getAnimal("狗")）
- 规则引擎注册时，要确保子类在类路径下且无重复类名，否则反射加载失败
- 日志和监控应打在父类方法入口，才能统一捕获所有子类行为，便于排查
