解释器模式
今天在看虚拟机相关实现代码时，遇到了解释器模式，由于之前没用过，特地搞清楚了这种设计模式。
背景
在银行、证券类项目里，经常会有一些模型的计算，通常是加、减、乘、除四则运算，当然不止这四种运算，还有更加复杂的运算公式，但是归根结底，框架都是一样的，只是实现的算法不同而已，我们来设计一个运算框架，来看看解释器模式在里面的运用。
初步设计
这样的设计一看就很清楚，通过抽象类Expression，各个具体实现的子类，比如负责加法运算，负责减法运算的类等等都需要继承这个抽象类。
优化设计
根据迪米特法则)，再通过Client类只与直接的朋友Calculator交流，与其他的类没关系。
解释器模式
解释器模式（Interpreter Pattern）是一种按照规定语法进行解析的方案，在现在项目中使用较少，其定义如下：给定一门语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。
- AbstractExpression——抽象解释器，具体的解释任务由各个实现类完成，具体的解释器分别由TerminalExpression和NonTerminalExpression完成。
- TerminalExpression终结符表达式，实现与文法中的元素相关联的解释操作，通常一个解释器模式中只有一个终结符表达式，但有多个实例，具体例子中是
- NonterminalExpression——非终结符表达式，具体到我们的例子就是加减法规则分别对应AddExpression和SubExpression两个类。
- Context——环境角色，具体到例子里是采用HashMap代替。
优点
解释器是一个简单的语法分析工具，最显著的特定就是扩展性，如果需要扩展语法，增加非终结符就可以了。
缺点
- 解释器会引起类膨胀
- 采用递归调用方法
- 效率问题