第26章解释器模式

课程目录第26章解释器模式

解释器模式：定义、结构、实现、优缺点、应用场景

解释器模式，说实话，在23种经典设计模式里算是个「小众选手」。我刚开始学的时候也觉得它有点鸡肋——谁会没事去自己写个解释器啊？

但后来我在一个金融风控项目里，真就遇到了需要动态解析业务规则的情况。那时候我才意识到，这玩意儿其实挺实用的。说白了，解释器模式就是给特定语言定义一套语法规则，然后用代码去解释执行它。

模式定义

解释器模式（Interpreter Pattern）属于行为型模式。它定义了一种方式，用来评估某个语言（或表达式）的语法。核心思路是：为语言中的每一种语法规则都定义一个类，然后通过组合这些类来构建复杂的表达式。

你想想看，这就像搭积木。每个小积木代表一个简单的语法规则，拼在一起就能表达复杂的逻辑。

模式结构

解释器模式的结构其实挺清晰的，我画了张图帮你理解：

结构中的几个角色，我一个个说：

AbstractExpression（抽象表达式）：声明一个抽象的 interpret() 方法，所有具体表达式都要实现它。
TerminalExpression（终结符表达式）：实现与语法规则中的终结符相关的解释操作。说白了就是「不能再拆」的最小单位。
NonterminalExpression（非终结符表达式）：每个语法规则对应一个类，内部会包含其他表达式，递归调用 interpret()。
Context（上下文）：包含解释器之外的全局信息，比如变量值、环境配置等。
Client（客户端）：构建抽象语法树，然后调用根节点的 interpret() 方法。

代码实现

我拿一个简单的「数学表达式计算器」来演示。假设我们要解析类似 "3 + 5 - 2" 这样的表达式。

先定义抽象表达式接口：

// 抽象表达式
public interface Expression {
    int interpret();
}

然后是数字表达式（终结符）：

// 终结符表达式 - 数字
public class NumberExpression implements Expression {
    private int number;
    
    public NumberExpression(int number) {
        this.number = number;
    }
    
    @Override
    public int interpret() {
        return number;
    }
}

加减法表达式（非终结符）：

// 非终结符表达式 - 加法
public class AddExpression implements Expression {
    private Expression left;
    private Expression right;
    
    public AddExpression(Expression left, Expression right) {
        this.left = left;
        this.right = right;
    }
    
    @Override
    public int interpret() {
        return left.interpret() + right.interpret();
    }
}

// 非终结符表达式 - 减法
public class SubtractExpression implements Expression {
    private Expression left;
    private Expression right;
    
    public SubtractExpression(Expression left, Expression right) {
        this.left = left;
        this.right = right;
    }
    
    @Override
    public int interpret() {
        return left.interpret() - right.interpret();
    }
}

客户端使用：

public class Client {
    public static void main(String[] args) {
        // 构建表达式: 3 + 5 - 2
        Expression expression = new SubtractExpression(
            new AddExpression(
                new NumberExpression(3),
                new NumberExpression(5)
            ),
            new NumberExpression(2)
        );
        
        int result = expression.interpret();
        System.out.println("计算结果: " + result); // 输出 6
    }
}

💡 我的小建议：实际项目中别手写解析器。如果语法规则超过10条，建议直接用ANTLR或JavaCC这类工具。我曾经在一个项目中手写了30多条规则的解释器，维护起来简直想哭。

优缺点分析

优点	缺点
易于扩展语法规则——加一个新规则就是加一个新类实现了语法与执行的分离每个语法规则独立成类，符合单一职责原则	语法规则多时，类数量爆炸式增长执行效率较低，递归调用有性能开销复杂语法难以维护，调试困难

⚠️ 避坑指南：我曾经接手过一个项目，里面用解释器模式实现了完整的SQL子集解析。结果呢？语法规则有80多条，类文件200多个。每次加一个新功能，都要改五六个类。后来我直接换成了ANTLR生成解析器，代码量减少了70%。所以记住：解释器模式只适合语法规则少且稳定的场景。

应用场景

解释器模式虽然小众，但用对地方还是很香的。我总结了几类典型场景：

简单的表达式计算：比如计算器、公式引擎。我在一个报表系统里就用它实现了自定义计算公式。
配置文件解析：像Spring的SpEL表达式，本质上就是解释器模式。
规则引擎：业务规则动态配置，比如风控系统中的规则判断。
模板引擎：像FreeMarker、Velocity这类模板语言，底层都有解释器的影子。
脚本语言解释器：比如Lua、Python的语法解析器。

核心要点回顾：

解释器模式 = 为每种语法规则定义一个类
终结符表达式是叶子节点，非终结符表达式是组合节点
适合语法规则少且稳定的场景
规则多时，优先考虑ANTLR等解析器生成工具

嗯，解释器模式就聊到这儿。它不像单例、工厂那样天天用，但遇到合适的场景，用起来是真的顺手。关键是把握好「度」——别为了用模式而用模式，那就得不偿失了。

📚 课程目录

解释器模式：定义、结构、实现、优缺点、应用场景

模式定义

模式结构

代码实现

优缺点分析

应用场景