## 01、痛点

我是老李。最近一个电商项目里，优惠资格判断的代码让我头大。一开始需求很简单：注册满 30 天且累计消费满 500 的用户，可以享受首单折扣。代码是这样的：

```java
if (user.getRegisterDays() > 30 && user.getTotalSpent() > 500) {
    return true;
}
```

后来运营提了一个新规则：VIP 用户只要订单金额超过 1000，也能享受。于是代码变成了：

```java
if (user.getRegisterDays() > 30 && user.getTotalSpent() > 500) {
    return true;
}
if (user.getLevel().equals("VIP") && order.getAmount() > 1000) {
    return true;
}
```

再后来，规则变成了：

- 注册满 30 天且累计消费满 500，或
- VIP 且订单金额 > 1000，或
- 注册满 10 天且订单金额 > 800 且非黑名单用户。

代码开始失控：

```java
if ((user.getRegisterDays() > 30 && user.getTotalSpent() > 500) 
    || (user.getLevel().equals("VIP") && order.getAmount() > 1000) 
    || (user.getRegisterDays() > 10 && order.getAmount() > 800 && !user.isBlacklist())) {
    return true;
}
```

再往后，运营要求规则可配置，不同活动用不同规则，不能每次改代码。if/else 堆得越来越深，一个方法几百行，新人根本不敢动。这个场景，就是解释器模式登场的时候。

> 锐评：如果规则只有两个稳定分支，if/else 完全够用。但规则一旦开始组合、嵌套、频繁变化，硬编码 if 就成了一坨“会呼吸的史前化石”。

## 02、是什么

解释器模式，说白了，就是为某种语言定义一套语法规则，再把每一条规则表示成一个类，然后通过组合这些类来“解释”一段表达式。

它不像策略模式那样切换算法，不像模板方法那样固定流程，它真正解决的是：**当业务规则本身需要被表达、解析、组合时，如何用代码结构去承载规则，而不是把规则写死在 if 里。**

核心角色：

- **AbstractExpression（抽象表达式）**：定义解释操作的接口。
- **TerminalExpression（终结符表达式）**：语法中的最小单元，比如变量、常量，它不会再包含其他表达式。
- **NonterminalExpression（非终结符表达式）**：由其他表达式组合而成的规则，比如 AND、OR、比较运算。
- **Context（上下文）**：存放解析过程中需要的全局信息，比如用户数据、订单数据。

比如规则 `registerDays > 30 AND totalSpent > 500`，可以表示成一棵抽象语法树（AST）：

```
            AND
           /   \
          >     >
         / \   / \
registerDays 30 totalSpent 500
```

`registerDays`、`30` 是终结符，`>`、`AND` 是非终结符。解释器模式的核心思想，就是把这棵树变成对象结构，然后递归解释。

## 03、为什么

为什么很多开发者学过解释器模式，却从来没用过？因为它的使用场景比较特殊：只有当规则本身需要动态变化、组合、解析时，才需要它。

常见误区有三个：

**误区一：看到表达式就想到解释器模式。**  
一个简单的 `if (age > 18)`，根本不需要解释器模式。

**误区二：规则一变复杂，就直接上重量级规则引擎（如 Drools）。**  
规则引擎功能强大，但引入成本高，学习曲线陡，很多场景下是杀鸡用牛刀。

**误区三：用正则或字符串拼接硬解析，导致更难维护。**  
为了“不写 if”而把规则写成字符串，然后正则匹配，结果比 if 还难懂。

判断是否值得使用解释器模式，可以问自己：

1. 规则是否由非开发人员配置或动态修改？
2. 规则组合是否越来越多，且需要灵活调整优先级和逻辑？
3. 是否希望通过配置文件或数据库存储规则，而不是改代码？
4. 规则语法是否相对简单，不涉及复杂控制流（循环、函数调用等）？

如果以上有几个是“是”，解释器模式可能合适；如果规则固定且少，老老实实写 if。

> 锐评：十行代码解决的问题，不要写成一场架构发布会。解释器模式不是让你把 if 拆成十个类，而是让你把“变化的部分”从代码中剥离出来。

## 04、架构

解释器模式的经典结构如下：

```
Client
  |
  | 构建表达式树
  v
AbstractExpression  <------------------+
  | interpret(context)                 |
  |                                    |
  +-- TerminalExpression               |
  |    (变量、常量)                    |
  |                                    |
  +-- NonterminalExpression -----------+
        (AndExpression, OrExpression,
         GreaterThanExpression, ...)
```

角色职责：

- **AbstractExpression**：定义 `interpret(Context)` 接口。
- **TerminalExpression**：实现终结符，比如获取某个变量的值、返回常量。
- **NonterminalExpression**：持有子表达式，实现组合逻辑，如 AND、OR、比较。
- **Context**：存放数据，一般是一个 Map 或一个领域对象。

在构建表达式树时，通常有两种方式：
- **手动构造**：直接 new 各种表达式对象，代码直观但繁琐。
- **解析器生成**：编写一个简单解析器，将字符串 DSL 解析成表达式树，适合规则外部化。

字符画展示一个规则 DSL 的解析过程：

```
规则字符串: "registerDays > 30 AND totalSpent > 500"
        |
        v
词法分析: [registerDays] [>] [30] [AND] [totalSpent] [>] [500]
        |
        v
语法分析: 构建表达式树
        |
        v
解释执行: 递归遍历树，结合 Context 计算结果
```

解释器模式本质上是一个**小型编译器**：词法分析、语法分析、解释执行。只是它通常只关注解释执行，解析部分可以手写或省略。

## 05、实战

### 一、业务场景

实现一个优惠资格规则解释器，支持以下语法：

- 变量：`registerDays`、`totalSpent`、`level`、`orderAmount`、`isBlacklist`
- 比较符：`>`、`<`、`==`
- 逻辑符：`AND`、`OR`
- 括号改变优先级（为简化演示，手动构造树可先不实现括号解析）

规则示例：  
`(registerDays > 30 AND totalSpent > 500) OR (level == "VIP" AND orderAmount > 1000)`

### 二、第一版代码

最初就是简单的 if 嵌套：

```java
public boolean checkPromotion(User user, Order order) {
    if (user.getRegisterDays() > 30 && user.getTotalSpent() > 500) {
        return true;
    }
    if ("VIP".equals(user.getLevel()) && order.getAmount() > 1000) {
        return true;
    }
    return false;
}
```

### 三、代码开始失控

规则越来越多，出现括号、优先级、动态配置需求，代码变成一坨：

```java
public boolean checkPromotion(User user, Order order) {
    boolean rule1 = user.getRegisterDays() > 30 && user.getTotalSpent() > 500;
    boolean rule2 = "VIP".equals(user.getLevel()) && order.getAmount() > 1000;
    boolean rule3 = user.getRegisterDays() > 10 && order.getAmount() > 800 && !user.isBlacklist();
    boolean rule4 = "GOLD".equals(user.getLevel()) && order.getAmount() > 2000 && user.getTotalSpent() > 1000;
    return rule1 || rule2 || rule3 || rule4;
}
```

每次新增规则都要改这个方法，测试用例要重写，运营还要你“把规则做成可配置的”。

### 四、模式重构

#### 1. 定义抽象表达式

```java
public interface Expression {
    Object interpret(Map<String, Object> context);
}
```

这里用 `Object` 作为返回值，实际业务中可根据需要设计更具体的类型。

#### 2. 终结符表达式

变量表达式：

```java
public class VariableExpression implements Expression {
    private String key;
    public VariableExpression(String key) { this.key = key; }
    @Override
    public Object interpret(Map<String, Object> context) {
        return context.get(key);
    }
}
```

常量表达式：

```java
public class ConstantExpression implements Expression {
    private Object value;
    public ConstantExpression(Object value) { this.value = value; }
    @Override
    public Object interpret(Map<String, Object> context) {
        return value;
    }
}
```

#### 3. 逻辑非终结符表达式

AndExpression：

```java
public class AndExpression implements Expression {
    private Expression left;
    private Expression right;
    public AndExpression(Expression left, Expression right) {
        this.left = left;
        this.right = right;
    }
    @Override
    public Object interpret(Map<String, Object> context) {
        Boolean l = (Boolean) left.interpret(context);
        Boolean r = (Boolean) right.interpret(context);
        return l && r;
    }
}
```

OrExpression 类似，将 `&&` 换成 `||`。

#### 4. 比较非终结符表达式

GreaterThanExpression：

```java
public class GreaterThanExpression implements Expression {
    private Expression left;
    private Expression right;
    public GreaterThanExpression(Expression left, Expression right) {
        this.left = left;
        this.right = right;
    }
    @Override
    public Object interpret(Map<String, Object> context) {
        Number l = (Number) left.interpret(context);
        Number r = (Number) right.interpret(context);
        return l.doubleValue() > r.doubleValue();
    }
}
```

LessThanExpression、EqualsExpression 类似。

#### 5. 构建表达式树

手动构造：

```java
Map<String, Object> context = new HashMap<>();
context.put("registerDays", 45);
context.put("totalSpent", 600);
context.put("level", "VIP");
context.put("orderAmount", 1200);

Expression rule = new OrExpression(
    new AndExpression(
        new GreaterThanExpression(new VariableExpression("registerDays"), new ConstantExpression(30)),
        new GreaterThanExpression(new VariableExpression("totalSpent"), new ConstantExpression(500))
    ),
    new AndExpression(
        new EqualsExpression(new VariableExpression("level"), new ConstantExpression("VIP")),
        new GreaterThanExpression(new VariableExpression("orderAmount"), new ConstantExpression(1000))
    )
);

boolean eligible = (Boolean) rule.interpret(context);
System.out.println("是否满足优惠资格: " + eligible); // true
```

### 五、结构变化

传统写法：

```
OrderService
|
+-- if (registerDays>30 && totalSpent>500)
+-- if (level==VIP && orderAmount>1000)
+-- if (registerDays>10 && orderAmount>800 ...)
```

重构后：

```
OrderService
|
v
Expression
├── VariableExpression
├── ConstantExpression
├── AndExpression
├── OrExpression
├── GreaterThanExpression
├── LessThanExpression
└── EqualsExpression
```

### 六、收益

- 规则与代码解耦，修改规则不需要改动核心逻辑。
- 可以灵活组合规则，甚至动态从配置文件或数据库构建表达式树。
- 每个表达式类职责单一，易于单元测试。
- 新增一种比较符或逻辑符，只需新增一个类，符合开闭原则。

### 七、代价

- 类数量增多，一个简单规则可能拆成十几个类。
- 阅读链路变长，需要理解抽象语法树的结构。
- 如果规则没有动态配置需求，抽象层就是多余。

### 八、什么时候不要用

- 规则固定且数量少，直接用 if 更清晰。
- 规则非常复杂，包含循环、函数调用等，解释器模式难以支撑，应选择规则引擎或通用脚本语言。
- 团队没有维护自定义 DSL 的能力，引入解释器模式反而增加负担。

> 锐评：解释器模式的本质是“把规则变成数据”。如果你的规则从来不变，那它只是一堆 if；如果规则经常变，还不做抽象，那就是在给自己埋雷。

## 06、洞见

解释器模式背后有几个值得细品的判断力。

**洞见一：解释器模式关注的不是“对象怎么创建”，而是“规则怎么表达”。**  
它不属于创建型，而是行为型。很多开发者误以为它只是解析字符串，其实它核心是构建对象树并递归解释。

**洞见二：AST 思想无处不在。**  
SQL 解析、Spring EL 表达式、MyBatis 动态 SQL、正则表达式、编译器前端，都在使用 AST。掌握解释器模式，等于理解了这些工具的底层逻辑。

**洞见三：框架中大量运用了解释器思想。**  
Spring 的 `SpEL` 就是一个典型的表达式解释器；MyBatis 的 `<if>`、`<choose>` 标签也是一种规则表达；甚至 Java 的正则引擎内部也是解释器模式。

**洞见四：会写解释器模式，不等于一定要自己写解析器。**  
很多时候复用现成表达式引擎（如 SpEL、MVEL、Aviator）是更务实的选择。自己写解析器通常只适合规则语法极简、且需要完全掌控的场景。

> 锐评：初级开发者把规则写死在 if 里，中级开发者会自己写解释器，高级开发者知道什么时候该用 SpEL，架构师能判断“这个规则根本不值得抽象”。

## 07、行动

想掌握解释器模式，别一上来啃 23 种模式。按下面三个阶段来。

**第一阶段：先理解核心结构。**  
手写一个最简单的解释器，只支持 `>` 和 `AND`，不用解析器，手动 new 表达式对象，把 Context 传入，跑通。

**第二阶段：扩展语法。**  
加入 `OR`、`<`、`==`，再试着实现一个简单的递归下降解析器，把字符串 `"age > 18 AND vip == true"` 解析成表达式树。这一阶段重点关注如何把输入字符串变成对象结构。

**第三阶段：从项目里找场景。**  
比如动态筛选条件、规则配置、计算表达式、权限控制等。遇到类似需求，先问自己：这个规则会不会频繁变？值不值得抽出来？如果值得，用解释器模式试试。

一个可执行的七天实践计划：

- Day 1：实现 Expression 接口和两个终结符（变量、常量）。
- Day 2：实现 GreaterThanExpression 和 AndExpression，手动构造树。
- Day 3：加入 OrExpression 和 LessThanExpression，测试组合规则。
- Day 4：写一个简单的字符串解析器，支持 `AND`、`OR`、括号。
- Day 5：把规则字符串放到配置文件，读取并解析执行。
- Day 6：评估代码：如果规则再变复杂，是不是应该换成 SpEL 或 Drools？
- Day 7：回看哪些抽象是必要的，哪些是过度设计。

## 08、小结

> 解释器模式不是为了让 if 消失，而是为了让规则不再写死在代码里。

设计模式最重要的，从来不是记住那 23 个名字，而是看到变化、识别变化、隔离变化的能力。解释器模式只是一个工具，它适合小型规则语言，不适合复杂语言系统。用对了，它能把一坨混乱的 if 变成一棵清晰的表达式树；用错了，它能把一个简单布尔判断变成十个类的阅读灾难。

如果读完这篇文章，你在写下一个优惠规则判断时，能少写 50 行 if/else，那这篇文章就算没有白写。

## 09、链接与概念说明

- **GoF**：指 Gang of Four（四人组），即《设计模式：可复用面向对象软件的基础》的四位作者。该书定义了 23 种经典设计模式，解释器模式是其中一种行为型模式。
- **创建型 / 结构型 / 行为型**：创建型关注对象创建（如工厂、单例），结构型关注类与对象的组合（如适配器、装饰器），行为型关注对象间的通信与职责分配（如策略、观察者、解释器）。
- **解释器模式与 SOLID**：解释器模式通过将每个语法规则封装成类，符合单一职责原则；新增规则只需新增类，符合开闭原则；但过度拆分可能导致接口隔离原则的破坏。
- **开闭原则**：对扩展开放，对修改关闭。解释器模式通过新增表达式类来扩展语法，而不修改已有类，这是它被推崇的重要原因。
- **推荐资料**：
  - 《设计模式：可复用面向对象软件的基础》—— GoF 经典，第 16 章专门讲解释器模式。
  - Martin Fowler 的《领域特定语言》—— 深入讨论 DSL 的设计与实现，与解释器模式高度相关。
  - Spring 官方文档中关于 SpEL 的章节—— 理解表达式引擎的实际应用。

我是老李。最近一个电商项目里，优惠资格判断的代码让我头大。一开始需求很简单：注册满 30 天且累计消费满 500 的用户，可以享受首单折扣。代码是这样的：

《设计模式军体拳第16招》 解释器模式 Interpreter——把业务规则变成可以执行的语言

从优惠资格判断的 if/else 失控开始，结合解释器模式核心角色与 AST 构造，用 Java 实现一个支持 AND/OR/比较运算的规则解释器，并清晰界定适

架构师

编程语言

架构设计

后端

优惠资格判断规则复杂多变，使用解释器模式将硬编码if/else重构为表达式树，实现规则与代码解耦，支持动态组合配置，大幅提升灵活性与可维护性。通过变量、比较、逻辑表达式的组合，应对多种业务规则变化，降低代码维护成本。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《设计模式军体拳第16招》 解释器模式 Interpreter——把业务规则变成可以执行的语言-腾讯云开发者社区-腾讯云

《设计模式军体拳第16招》解释器模式 Interpreter——把业务规则变成可以执行的语言

《设计模式军体拳第16招》解释器模式 Interpreter——把业务规则变成可以执行的语言

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《设计模式军体拳第16招》 解释器模式 Interpreter——把业务规则变成可以执行的语言

《设计模式军体拳第16招》 解释器模式 Interpreter——把业务规则变成可以执行的语言

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《设计模式军体拳第16招》解释器模式 Interpreter——把业务规则变成可以执行的语言

《设计模式军体拳第16招》解释器模式 Interpreter——把业务规则变成可以执行的语言