项目中有时会遇到某类问题出现得非常频繁，而且它们的变化也基本上以一些规律性的方式进行变化。对于这类问题，如果编写一个对象类进行处理，随着业务变更，将需要频繁地修改代码、编译、部署。与其反复做这种工作，不如把它们抽象为一个语言（语法定义可能很简单，也可能很复杂），这样就可以极大地增加代码的业务适应性。
正则表达式就是解释器模式的一种应用；再比如，假设有这样的业务场景 ：部门经理可以审批员工的办公用品申请，但如果某个申请单的金额大于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<string, int> var);}public class VarExpression : IExpression{ private string key; public VarExpression(string key) { this.key = key; } public int Interpreter(Dictionary<string, int> 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<string, int> var);}//加法解析器public class AddExpression : SymbolExpression{ public AddExpression(IExpression left, IExpression right) : base(left, right) { } public override int Interpreter(Dictionary<string, int> 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<string, int> var) { return this.left.Interpreter(var) - this.right.Interpreter(var); }}public class Calculator{ private IExpression expression; public Calculator(string exp) { //定义一个栈，安排运算的先后顺序 Stack<IExpression> stack = new Stack<IExpression>(); //表达式拆分为字符数组 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<string, int> var) { return this.expression.Interpreter(var); }}调用:
string exp = "a+b-c";Dictionary<string, int> var = new Dictionary<string, int>();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类图可知解释器模式包含这几个角色：
- Context，环境角色，保存了解释器运行需要的上下文；
- AbstractExpression，抽象表达式，是所有计算表达式的抽象接口，表示当前表达式节点及其分支下所有节点，具体的解释任务分别由TerminalExpression和NonTerminalExpression完成；
- TerminalExpression，终结符表达式，示例中的VarExpression，实现与文法中的元素相关联的解释操作，通常一个解释器模式中只有一个终结符表达式，但有多个实例，对应不同的终结符。
- NonTerminalExpression，非终结符表达式，示例中的AddExpression和SubExpression，非终结符表达式根据逻辑的复杂程度而增加，原则上每个文法规则都对应一个非终结符表达式。
适用场景
- 虽然相关操作频繁出现，而且也有一定规律可循，但如果通过大量层次性的类来表示这种操作，设计上显得比较复杂。
- 执行上对效率的要求不是特别高，但对于灵活性的要求非常高。
优点
- 可扩展性比较好
- 增加了新的解释表达式的方式。
- 易于实现简单文法。
缺点
- 可利用场景比较少。
- 对于复杂的文法比较难维护。
- 解释器模式会引起类膨胀。
- 解释器模式采用递归调用方法，性能较差。
解释器是一个比较少用的模式，如果确实遇到"一种特定类型的问题发生的频率足够高"的情况，准备使用解释器模式时，建议优先考虑一些成熟的第三方、开源的解析工具。
参考书籍：
王翔著 《设计模式——基于C#的工程化实现及扩展》
没有评论:
发表评论