核心是让每条规则自行实现ruleevaluator接口的matches()方法，通过统一输入上下文和多态调用实现解耦；新增规则只需添加实现类、bean注解和开关配置，主干代码零修改。

核心是把“谁来判断”变成“谁自己回答”，而不是让调度方去识别类型再分发。

定义统一规则判定接口

所有业务规则必须实现同一个接口，比如 RuleEvaluator，只暴露一个关键方法：
boolean matches(ExecutionInput input)
这个方法返回当前规则是否适用。输入参数用通用容器（如 Map 或自定义上下文类）封装所有可能用到的字段，避免接口随业务膨胀。不加任何具体字段名（如 “orderAmount”“userId”），保持接口稳定。

每个规则封装为独立实现类

每条业务规则对应一个具体类，各自实现 matches() 方法：

• HighRiskOrderRule：查风控模型、比对历史欺诈率，决定是否拦截
• VipEligibilityRule：读取会员等级缓存 + 活动白名单配置，判断是否可参与
• BudgetLimitRule：调预算服务接口，结合部门编码和本次申请金额做动态校验

每个类内部处理全部细节——查库、调远程、解析配置、打日志，对外只呈现“是/否”结果。

规则引擎按需加载并统一调用

引擎本身不写 if/else 或 switch，也不用 instanceof：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 规则注册时，通过 Spring Bean 名称或简单工厂获取 RuleEvaluator 实例
• 执行时只做一件事：evaluator.matches(context)
• 若需组合逻辑（如 AND 多个规则），让 CompositeRule 也实现同一接口，递归调用子规则

日志、耗时统计、失败原因都统一埋点在 matches() 入口，便于横向对比各规则表现。

保障多态真正生效的关键约束

写了 implements 不等于多态就起作用，必须满足：

• 引擎持有的变量类型必须是 RuleEvaluator，不能是具体子类（如不能声明为 HighRiskOrderRule r = ...）
• matches() 方法不能是 static、private 或 final
• 子类必须真正重写该方法，签名（包括返回值、参数类型、异常声明）完全一致
• 类路径中不能存在同名但不同包的 RuleEvaluator 实现，否则类加载可能出错

这样建模后，新增一条规则只需写一个新类、加个 Spring Bean 注解、配个启用开关，主干代码零修改。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南