用接口标注对象能力比if-else更清晰易维护，如订单实现riskcheckable、billable、notifiable接口，引擎按类型自动路由，各方法自治、协作靠注入，支持即插即用扩展。
直接用接口标注对象能力，比在逻辑引擎里靠 if-else 或类型判断分拣更清晰、更易维护。
用接口明确声明对象“能做什么”
不要让引擎去猜一个对象该走哪条分支，而是让它自己说清楚。比如订单对象要参与风控、计费、通知三个流程，就让它实现 RiskCheckable、Billable、Notifiable 三个接口。每个接口只定义一个核心方法，如 checkRisk()、calculateFee()、getNotifyTargets()。逻辑引擎按接口类型扫描、分发，不依赖字段名或字符串标识。
引擎侧按接口类型自动路由
在规则调度或工作流引擎中，避免写死类名或配置映射表。可采用以下方式：
- 注册阶段：将实现了 Billable 的所有类自动加入“计费处理器池”
- 运行时：遍历待处理对象集合，对每个对象调用
if (obj instanceof Billable)判断并投递 - 进阶做法：用反射+注解预扫描，构建接口→处理器的缓存映射，启动即加载，零反射开销
避免行为混杂与隐式依赖
多个接口共存时，容易在实现中悄悄耦合。例如 Notifiable.send() 内部又调了 checkRisk()，导致通知失败牵连风控逻辑。应做到：
- 各接口方法保持自治，只读自身字段或传入参数
- 跨能力协作通过构造注入（如
new OrderNotifier(riskValidator)），而非在方法体内硬调其他接口 - 单元测试分别验证单个接口行为，再组合验证协同路径
替换与扩展不碰主线逻辑
某天要给特定客户启用新计费策略，只需新增一个 CustomBillable 实现类，注册进引擎，无需修改原有 Billable 处理器代码，也不影响风控和通知流程。这种“能力即插即用”的结构，让逻辑引擎真正变成可装配的骨架，而不是越长越重的巨石。
