Java项目重构：使用规则执行器优雅解决复杂条件判断问题

近日，我们在对现有系统的一个“试用用户申请”功能进行规则拓展时，遇到了一个典型的代码维护难题。最初的规则逻辑由一系列嵌套的 if 语句构成，虽然能够满足功能需求，但随着规则变得复杂，其可读性和可维护性急剧下降。

业务场景与问题分析

我们的原始规则逻辑大致如下：

if (是否海外用户) {
    return false;
}

if (刷单用户) {
    return false;
}

if (未付费用户 && 不再服务时段) {
    return false
}

if (转介绍用户 || 付费用户 || 内推用户) {
    return true;
}

面对这段代码，我们可以清晰地看到几个特点：

1. 核心逻辑是基于 and（与）或者 or（或）的关系组合。
2. 逻辑本身具有“短路”特性，即一旦某个条件不匹配，后续流程无需执行。
3. 虽然直接在原有代码上堆叠新的 if 条件也能快速满足新需求，但这无疑会加剧代码的“腐化”，让后续的维护和迭代变得异常困难。

权衡之后，我们决定对这部分逻辑进行重构，目标是设计一个清晰、可扩展、易维护的规则执行引擎。

规则执行器的设计与实现

针对上述需求，我们设计了规则执行器的 V1 版本。其核心思想是将规则抽象化、执行逻辑标准化，从而实现规则与业务逻辑的解耦。

规则执行器整体设计

首先，我们来看一下规则执行器的整体交互流程设计：

整个流程从客户端（Client）发起调用开始，规则执行器会整合业务数据，并通过规则构建器组织规则列表，最后执行规则并返回结果。

规则抽象与具体实现

设计的首要步骤是对规则进行抽象。我们定义一个统一的规则接口，并为常用功能提供一个抽象模板类。

1. 定义业务数据对象：

// 业务数据
@Data
public class RuleDto {
    private String address;
    private int age;
}

2. 定义基础规则接口：

// 规则抽象
public interface BaseRule {
    boolean execute(RuleDto dto);
}

3. 创建规则抽象模板类（运用了模板方法模式）：

// 规则模板
public abstract class AbstractRule implements BaseRule {

    protected <T> T convert(RuleDto dto) {
        return (T) dto;
    }

    @Override
    public boolean execute(RuleDto dto) {
        return executeRule(convert(dto));
    }

    protected <T> boolean executeRule(T t) {
        return true;
    }
}

这个抽象类 AbstractRule 是本次设计的巧妙之处。它提供了默认的 convert 方法用于数据转换，并定义了执行流程的骨架。具体的规则只需继承它并重写关键方法即可。

4. 实现具体规则：
下面我们实现两个具体的规则作为示例。

规则一：地址规则

// 具体规则- 例子1
public class AddressRule extends AbstractRule {

    @Override
    public boolean execute(RuleDto dto) {
        System.out.println(“AddressRule invoke!”);
        if (dto.getAddress().startsWith(MATCH_ADDRESS_START)) {
            return true;
        }
        return false;
    }
}

规则二：国籍规则

// 具体规则- 例子2
public class NationalityRule extends AbstractRule {

    @Override
    protected <T> T convert(RuleDto dto) {
        NationalityRuleDto nationalityRuleDto = new NationalityRuleDto();
        if (dto.getAddress().startsWith(MATCH_ADDRESS_START)) {
            nationalityRuleDto.setNationality(MATCH_NATIONALITY_START);
        }
        return (T) nationalityRuleDto;
    }

    @Override
    protected <T> boolean executeRule(T t) {
        System.out.println(“NationalityRule invoke!”);
        NationalityRuleDto nationalityRuleDto = (NationalityRuleDto) t;
        if (nationalityRuleDto.getNationality().startsWith(MATCH_NATIONALITY_START)) {
            return true;
        }
        return false;
    }
}

注意 NationalityRule，它重写了 convert 方法，为当前规则创建了专用的数据对象 NationalityRuleDto。这展示了抽象模板如何为特定规则提供定制化数据转换的能力，是解决规则间数据依赖性的一个思路。

5. 常量定义：

// 常量定义
public class RuleConstant {
    public static final String MATCH_ADDRESS_START = “北京”;
    public static final String MATCH_NATIONALITY_START = “中国”;
}

执行器的构建

接下来是规则执行器 RuleService 的核心，它负责组织和执行规则链，并处理 AND 与 OR 的逻辑关系。

public class RuleService {

    private Map<Integer, List<BaseRule>> hashMap = new HashMap<>();
    private static final int AND = 1;
    private static final int OR = 0;

    public static RuleService create() {
        return new RuleService();
    }

    public RuleService and(List<BaseRule> ruleList) {
        hashMap.put(AND, ruleList);
        return this;
    }

    public RuleService or(List<BaseRule> ruleList) {
        hashMap.put(OR, ruleList);
        return this;
    }

    public boolean execute(RuleDto dto) {
        for (Map.Entry<Integer, List<BaseRule>> item : hashMap.entrySet()) {
            List<BaseRule> ruleList = item.getValue();
            switch (item.getKey()) {
                case AND:
                    // 如果是 and 关系，同步执行
                    System.out.println(“execute key = ” + 1);
                    if (!and(dto, ruleList)) {
                        return false;
                    }
                    break;
                case OR:
                    // 如果是 or 关系，并行执行
                    System.out.println(“execute key = ” + 0);
                    if (!or(dto, ruleList)) {
                        return false;
                    }
                    break;
                default:
                    break;
            }
        }
        return true;
    }

    private boolean and(RuleDto dto, List<BaseRule> ruleList) {
        for (BaseRule rule : ruleList) {
            boolean execute = rule.execute(dto);
            if (!execute) {
                // and 关系匹配失败一次，返回 false
                return false;
            }
        }
        // and 关系全部匹配成功，返回 true
        return true;
    }

    private boolean or(RuleDto dto, List<BaseRule> ruleList) {
        for (BaseRule rule : ruleList) {
            boolean execute = rule.execute(dto);
            if (execute) {
                // or 关系匹配到一个就返回 true
                return true;
            }
        }
        // or 关系一个都匹配不到就返回 false
        return false;
    }
}

执行器的调用示例

最后，我们来看一下如何使用这个规则执行器。调用方代码变得非常清晰和规整。

public class RuleServiceTest {

    @org.junit.Test
    public void execute() {
        //1. 定义规则  init rule
        AgeRule ageRule = new AgeRule();
        NameRule nameRule = new NameRule();
        NationalityRule nationalityRule = new NationalityRule();
        AddressRule addressRule = new AddressRule();
        SubjectRule subjectRule = new SubjectRule();

        //2. 构造需要的数据 create dto
        RuleDto dto = new RuleDto();
        dto.setAge(5);
        dto.setName(“张三”);
        dto.setAddress(“北京”);
        dto.setSubject(“数学”);;

        //3. 通过以链式调用构建和执行 rule execute
        boolean ruleResult = RuleService
                .create()
                .and(Arrays.asList(nationalityRule, nameRule, addressRule))
                .or(Arrays.asList(ageRule, subjectRule))
                .execute(dto);
        System.out.println(“this student rule execute result :” + ruleResult);
    }
}

通过链式调用的方式，我们将 国籍、姓名、地址 三个规则设置为“与”（AND）关系，将 年龄、科目 两个规则设置为“或”（OR）关系，逻辑一目了然。

总结与思考

通过引入规则执行器，我们成功地将杂乱的 if-else 丛林重构为结构清晰的规则体系。我们来总结一下这种模式的优缺点：

优点：

1. 结构清晰，职责分离：规则定义、数据准备、执行逻辑被拆分到不同的类中，符合单一职责原则。调用方的代码非常规整。
2. 易于扩展和维护：新增或修改规则只需创建新的规则类或修改现有类，无需改动核心执行逻辑。这种设计模式的运用极大地提升了代码的可维护性。
3. 提供灵活的数据转换：在抽象规则模板中定义的 convert 方法，为特定规则所需的数据转换提供了扩展点，增强了灵活性。

缺点：

1. 规则间可能存在数据依赖：如果多个规则严重依赖于对公共 DTO 对象的修改，会带来隐含的耦合。更好的做法是在执行前，就为所有规则构建好完整、独立的数据上下文。

总体来看，在面对复杂的、可能频繁变化的业务规则时，采用规则执行器或规则引擎是一种值得考虑的架构选择。它虽然引入了一定的复杂度，但换来的是长期的可维护性和灵活性。如果你也在为 Java 项目中复杂的条件判断逻辑而烦恼，不妨尝试一下这种重构思路。更多关于代码架构和重构的讨论，欢迎来到 云栈社区 与开发者们一同交流。