标签： 设计模式初涉
描述性文字
解释器模式是一个用的比较少的设计模式，而且不太好理解，先说下概念相关的东西
再写个代码示例帮助下理解：
定义
给定一个语言之后，解释器模式可以定义出其文法的一种表示，并同时提供一个
解释器，客户端可以使用这个解释器来解释这个语言中的句子。
四个角色
AbstractExpression：抽象表达式，声明一个所有具体表达式都要实现的接口，
接口中主要是一个interpret()方法，称为解释操作，具体的解释任务由他的各个实现
类来完成，而具体的解释器又分别由 终结符解释器 与 非终结符解释器 完成。TerminalExpression：终结符表达式，实现与文法中的元素相关联的解释操作，
通常一个解释器模式中只有一个终结符表达式，但有多个实例，对应不同的终结符。、
终结符一半是文法中的运算单元，比如有一个简单的公式R=R1+R2，在里面R1和R2就是终结符，
对应的解析R1和R2的解释器就是终结符表达式。NonterminalExpression ：非终结符表达式，文法中的每条规则对应于一个非终
结符表达式，非终结符表达式一般是文法中的运算符或者其他关键字，比如公式R=R1+R2中，
+就是非终结符，解析+的解释器就是一个非终结符表达式。非终结符表达式根据逻辑的复杂
程度而增加，原则上每个文法规则都对应一个非终结符表达式。Context：上下文环境，存放文法中各个终结符所对应的具体值，比如R=R1+R2，我们
给R1赋值100，给R2赋值200。这些信息需要存放到环境角色中，很多情况下我们使用Map来充
当环境角色就足够了。
UML类图
优缺点
优点
- 1.易于实现简易语法，一条语法规则用一个解释器对象解释执行
- 2.易于扩展新的语法，只需创建相应的解释器对象，在创建抽象语法树的时候使用即可。
- 3.增加了新的解释表达式的方式
缺点
- 1.可使用场景较少
- 2.对于复杂的文法比较难维护
- 3.引起类膨胀
- 4.采用递归调用方法，效率，性能，维护问题
使用场景
- 1.重复发生的问题
- 2.一个简单语法需要解释的场景
- 3.将一个解释执行的语言中的句子表示为一个抽象语法树
代码示例
定义一个能够解释加减法的解释器作为示例
先定义抽象表达式
接着定义加减法两个非终结符表达式
再接着定义常量与变量两个终结符表达式
然后定义上下文环境，用Map存放各个终结符对应的具体值
最后客户端调用
输出结果
可能看到输出结果的你还是一脸懵逼，到底解释器模式做了些什么？
答：定义了一套简单语法，每个终结符都有一个对应的值存起来了，
然后当你输了一串终结符，最后解释能得出一个正确结果。
本节示例代码：
https://github.com/coder-pig/DesignPatternsExample/tree/master/19.Interpreter%20Pattern
