摘要：解释器模式是一种行为型设计模式，用于定义文法规则并解释特定语言的表达式。核心思想是将语言中的元素（终结符/非终结符）转化为对象结构，通过递归解释建立语义解析。典型应用包括SQL解析、数学表达式计算（如"3+5*2"）和规则引擎。该模式通过Expression接口、TerminalExpression（如数字）和NonTerminalExpression（

定义解析

解释器模式（Interpreter Pattern）是 Java 设计模式中的一种行为型模式，用于给定语言定义其文法表示，并构建一个解释器来解释语言中的句子。

解析
当你发明了一种规则语言或表达式格式时，用代码来分析并执行这些表达式的套路。它就像为“你自己创造的语言”编写一个小型翻译器。
举个例子：

设计计算器，输入 "3 + 5 * 2"，用解释器模式来得到结果13。

解释器模式的目标就是——实现一套“语言”并能解析它的表达式。

应用场景

• SQL 解析器
  例如：SELECT * FROM user WHERE age > 18 AND gender = ‘男’;数据库系统内部必须**“读懂”这句话**，分析你要从哪个表里查、查哪些字段、什么条件。
• 数学表达式求值（如 "3 + 5 * (2 - 1)"）
  做一个在线计算器，用户输入字符串表达式：“3 + 5 * (2 - 1)”，程序自动计算结果 = 8。
• 自定义规则引擎（如：“年龄 > 18 且 性别为男”）
  比如公司招聘系统需要写一套规则系统，其中采用"年龄 > 18 且 性别 = 男"，用来过滤用户，判断是否满足某条件。
• 编译器前端、脚本语言解释器等
  脚本语言也是一种“语言”。编译器前端需要对脚本进行词法分析、语法分析、构建语法树，然后解释执行。这就符合解释器模式的典型架构。

模式结构

解释器模式一般包括：

1. 抽象表达式（Expression）
2. 终结符表达式（TerminalExpression）
   不能再分的基本表达式（如数字、变量）
3. 非终结符表达式（NonTerminalExpression）
   包含终结符或其他非终结符（如加法、乘法）
4. 上下文（Context）
   存储解释器所需的外部信息（如变量的值）

实战演示

我们构建一个简单的四则运算解释器，采用数学表达式解释器，支持加法和减法。依照模式结构代码如下：

1. 抽象表达式接口

public interface Expression {
int interpret();
}

2. 数字（终结符表达式）

public class Number
implements Expression {
private int value;
public Number(int value) {
this.value = value;
}
public int interpret() {
return value;
}
}

3. 加法表达式（非终结符）

public class Add
implements Expression {
private Expression left, right;
public Add(Expression left, Expression right) {
this.left = left;
this.right = right;
}
public int interpret() {
return left.interpret() + right.interpret();
}
}

4. 减法表达式（非终结符）

public class Subtract
implements Expression {
private Expression left, right;
public Subtract(Expression left, Expression right) {
this.left = left;
this.right = right;
}
public int interpret() {
return left.interpret() - right.interpret();
}
}

5. 客户端测试

public class Main
{
public static void main(String[] args) {
// 表达式：(5 + 3) - 2
Expression expr = new Subtract(
new Add(new Number(5), new Number(3)),
new Number(2)
);
System.out.println("结果: " + expr.interpret());
// 输出 6
}
}

类图结构

总结

优点

• 易于扩展语言规则：添加乘法、除法，只需扩展表达式类。
• 结构清晰：用类结构直接表达文法规则。

缺点

• 类爆炸：每种语法规则都需要一个类。
• 性能差：适用于简单解释器（复杂语法建议使用编译器框架）。

参考

《23种设计模式概览》

附：
@startuml
title Interpreter Pattern - Arithmetic Expression Example

interface Expression {
+interpret(): int
}

class Number implements Expression {
-value: int
+Number(value: int)
+interpret(): int
}

abstract class AbstractOperation implements Expression {
-left: Expression
-right: Expression
+AbstractOperation(left: Expression, right: Expression)
+interpret(): int
}

class Add extends AbstractOperation {
+interpret(): int
}

class Subtract extends AbstractOperation {
+interpret(): int
}

Expression <|… Number
Expression <|… AbstractOperation
AbstractOperation <|-- Add
AbstractOperation <|-- Subtract

@enduml