手写一个表达式计算器。你就理解解释器模式了

写过计算器的都知道，解析一个数学表达式有多麻烦。加减乘除、括号优先级、变量替换…，如果你用一堆 if‑else 来硬刚，代码会膨胀到让你自己都看不懂。

解释器模式就是干这个活的：给一种“语言”定义语法规则，接下来用代码来解释执行它。

解释器模式到底解决什么问题

你是否曾经在开发电商促销程序时运营频繁改规则，却每次都要重新部署？这正是解释器模式想要解决的问题：

• 把业务规则变成一种小语言。让程序直接“读懂”并执行，而不是硬编码。老实说，
• 降低运维成本。让业务人员可以通过配置而不是代码来调整策略。

再举几个你一定见过的例子：

• SQL 查询语句，数据库引擎就是 SQL 的解释器。
• 正则表达式，regex 引擎在解释你写的模式串。
• 模板引擎，解释模板里的 ${} 占位符。
• Spring 的 SpEL，在运行时解析表达式。怎么说呢，

这些本质上都是解释器模式的应用。

解释器模式的主要结构

• AbstractExpression: 定义统一的 interpret 方法。
• TerminalExpression: 处理语法中最小单位，比如数字、变量名。怎么说呢，
• NonTerminalExpression: 处理组合规则。比如加法、减法等运算符，
• Context: 用来存放运行时变量和状态。

Context
| AbstractExpression
├── TerminalExpression
└── NonTerminalExpression

至于动手写一个，四则运算解释器

先定义抽象表达式：

public interface Expression {
int interpret;}

终结符表达式——处理数字和变量：

// 数字
public class NumberExpression implements Expression {
private final int number;public NumberExpression { this.number = number;}
@Override
public int interpret { return number;}
}
// 变量
public class VariableExpression implements Expression {
private final String name;public VariableExpression { this.name = name;}
@Override
public int interpret {
return context.getOrDefault;}
}

非终结符表达式——加减乘除：

public class AddExpression implements Expression {
private final Expression left;private final Expression right;
public AddExpression {
this.left = left;this.right = right;}
@Override
public int interpret {
return left.interpret + right.interpret;说起来，}
}

组装并解析示例表达式：

Map vars = new HashMap<>;vars.put，vars.put;vars.put，// 表达式：a + b * c -
Expression expr = new SubtractExpression(
new AddExpression(
new VariableExpression。new MultiplyExpression(
new VariableExpression,new VariableExpression
)
),new SubtractExpression(
new VariableExpression,new VariableExpression
)
);int result = expr.interpret;// 自动递归求值
System.out.println;// 输出结果

你看，解释器把表达式变成了一个语法树. 每个节点都是一个 expression 。interpret  ““;不过，最终得到结果.

"实际踩过的坑"

• 当业务规则从简单四则 到 AND/OR/比较运算时我不得不为每种新语法编写额外类。维护成本直线上升，
• 字符串类型比较导致我们必须实现额外的数据类型支持，这又一次拉长了开发周期。
• 最终。我意识到自己可以用 ANTLR 或者现成框架来完成，但那代表着学习新工具与集成成本更高。
• 对比后发现。对于仅支持 AND/OR 的简单条件过滤，“手写一套轻量级解析”反而更快且占用资源更少。
---

"什么时候别用"

这个我要说句实话：““.

要解析 SQL？用 MyBatis/Hibernate 

要解析表达式？用 Spring EL / OGNL / SpEL 

要做规则引擎？用 Drools / LiteFlow 

要做模板渲染？用 FreeMarker / Thymeleaf 

i>

除非你的产品本身就是一个 DSL 编辑器，或者你的规则程序有特殊需求现有工具覆盖不了否则手写解析大概率是过度设计。

---

一句话

text 解释师模式教会你的不是“怎么手写完整语言”，而是让你理解 **语法树、递归解析、上下文传递** 等概念。这些概念在你阅读 ANTLR 或编译原理书籍时会显得尤为关键。

我正在做一个微信小程序「爪爪代码冒险记」 —— 用漫画+答题方式讲解设计模式。如果觉得此类内容有意思，请搜索「爪爪代码冒险记」或等待后续文章。每篇文章都会同步对应的小程序内容。