设计模式(15) 解释器模式

项目中有时会遇到某类问题出现得非常频繁，而且它们的变化也基本上以一些规律性的方式进行变化。对于这类问题，如果编写一个对象类进行处理，随着业务变更，将需要频繁地修改代码、编译、部署。与其反复做这种工作，不如把它们抽象为一个语言（语法定义可能很简单，也可能很复杂），这样就可以极大地增加代码的业务适应性。
正则表达式就是解释器模式的一种应用；再比如，假设有这样的业务场景 ：部门经理可以审批员工的办公用品申请，但如果某个申请单的金额大于1万，那么部门经理就没有权限审批了。这个逻辑可以表示为：

本部门员工（申请单） AND 申请单.金额小于10万

类似的规则常常会发生更改，比如可能需要增加一条：如果员工本身是行政助理，他收集全部门办公用品单，为了简化手续，每个部门的办公用品可以由他一个人挂名申请，因此金额可以大于1万，这时就需要修改这个表达式。所以在这类场景下，可以考虑增加一个能读懂这个表达式的子系统，在牺牲一些效率的情况下，专门解释执行类似的表达式。

解释器模式

解释器模式被用来解决单纯堆叠类结构难于应付业务变化的问题。
GOF对解释器模式的描述为：
Given a language, define a represention for its grammar along with an interpreter that uses the representation to interpret sentences in the language..
— Design Patterns : Elements of Reusable Object-Oriented Software

代码示例：
下面是利用解释器模式实现的一个简单的只支持加减法的计算器

public interface IExpression
{
    //解析公式和数值，其中var中的key-val是参数-具体数字
    int Interpreter(Dictionary var);
}

public class VarExpression : IExpression
{
    private string key;
    public VarExpression(string key)
    {
        this.key = key;
    }

    public int Interpreter(Dictionary var)
    {
        return var[this.key];
    }
}

public abstract class SymbolExpression : IExpression
{
    protected IExpression left;
    protected IExpression right;
    public SymbolExpression(IExpression left, IExpression right)
    {
        this.left = left;
        this.right = right;
    }

    public abstract int Interpreter(Dictionary var);
}

//加法解析器
public class AddExpression : SymbolExpression
{
    public AddExpression(IExpression left, IExpression right) : base(left, right) { }
    public override int Interpreter(Dictionary var)
    {
        return this.left.Interpreter(var) + this.right.Interpreter(var);
    }
}

//减法解析器
public class SubExpression : SymbolExpression
{
    public SubExpression(IExpression left, IExpression right) : base(left, right) { }
    public override int Interpreter(Dictionary var)
    {
        return this.left.Interpreter(var) - this.right.Interpreter(var);
    }
}

public class Calculator
{
    private IExpression expression;

    public Calculator(string exp)
    {
        //定义一个栈，安排运算的先后顺序
        Stack stack = new Stack();

        //表达式拆分为字符数组
        char[] charArray = exp.ToCharArray();

        //构建表达式树
        IExpression left = null;
        IExpression right = null;
        for (int i = 0; i < charArray.Length; i++)
        {
            switch (charArray[i])
            {
                case '+':
                    left = stack.Pop();
                    right = new VarExpression(charArray[++i].ToString());
                    stack.Push(new AddExpression(left, right));
                    break;
                case '-':
                    left = stack.Pop();
                    right = new VarExpression(charArray[++i].ToString());
                    stack.Push(new SubExpression(left, right));
                    break;
                default: //公式中的变量
                    stack.Push(new VarExpression(charArray[i].ToString()));
                    break;
            }
        }
        this.expression = stack.Pop();
    }

    public int Run(Dictionary var)
    {
        return this.expression.Interpreter(var);
    }
}

调用:

string exp = "a+b-c";
Dictionary var = new Dictionary();
var.Add("a", 3);
var.Add("b", 5);
var.Add("c", 7);

Calculator calculator = new Calculator(exp);
Console.WriteLine(calculator.Run(var)); //结果=1

这里有两个关键点：自定义的语言和那个Context对象，它们是贯穿解释器始终的对象，至于解释器的骨架则是由一个个表达式对象完成的，解释器的作用是把Context放进去，然后调度一个个表达式对象，直至完成整个语言的解释过程。

UML类图：

解释器模式 UML类图

从UML类图可知解释器模式包含这几个角色：

• Context，环境角色，保存了解释器运行需要的上下文；
• AbstractExpression，抽象表达式，是所有计算表达式的抽象接口，表示当前表达式节点及其分支下所有节点，具体的解释任务分别由TerminalExpression和NonTerminalExpression完成；
• TerminalExpression，终结符表达式，示例中的VarExpression，实现与文法中的元素相关联的解释操作，通常一个解释器模式中只有一个终结符表达式，但有多个实例，对应不同的终结符。
• NonTerminalExpression，非终结符表达式，示例中的AddExpression和SubExpression，非终结符表达式根据逻辑的复杂程度而增加，原则上每个文法规则都对应一个非终结符表达式。

适用场景

• 虽然相关操作频繁出现，而且也有一定规律可循，但如果通过大量层次性的类来表示这种操作，设计上显得比较复杂。
• 执行上对效率的要求不是特别高，但对于灵活性的要求非常高。

优点

• 可扩展性比较好
• 增加了新的解释表达式的方式。
• 易于实现简单文法。

缺点

• 可利用场景比较少。
• 对于复杂的文法比较难维护。
• 解释器模式会引起类膨胀。
• 解释器模式采用递归调用方法，性能较差。

解释器是一个比较少用的模式，如果确实遇到“一种特定类型的问题发生的频率足够高”的情况，准备使用解释器模式时，建议优先考虑一些成熟的第三方、开源的解析工具。

参考书籍：
王翔著 《设计模式——基于C#的工程化实现及扩展》