比如，可以使用解释器模式模拟状态模式的功能。如果把解释器模式要处理的语法简化到只有一个状态标记，把解释器看成是对状态的处理对象，对同一个表示状态的语法，可以有很多不用的解释器，也就是有很多不同的处理状态的对象，然后再创建抽象语法树的时候，简化成根据状态的标记来创建相应的解释器，不用再构建树了。
同理，解释器模式可以模拟实现策略模式的功能，装饰器模式的功能等，尤其是模拟装饰器模式的功能，构建抽象语法树的过程，自然就对应成为组合装饰器的过程。
解释器模式执行速度通常不快（大多数时候非常慢），而且错误调试比较困难（附注：虽然调试比较困难，但事实上它降低了错误的发生可能性），但它的优势是显而易见的，它能有效控制模块之间接口的复杂性，对于那种执行频率不高但代码频率足够高，且多样性很强的功能，解释器是非常适合的模式。此外解释器还有一个不太为人所注意的优势，就是它可以方便地跨语言和跨平台。
解释器模式的优缺点：
优点：
1.易于实现语法
在解释器模式中，一条语法规则用一个解释器对象来解释执行。对于解释器的实现来讲，功能就变得比较简单，只需要考虑这一条语法规则的实现就可以了，其他的都不用管。 2.易于扩展新的语法
正是由于采用一个解释器对象负责一条语法规则的方式，使得扩展新的语法非常容易。扩展了新的语法，只需要创建相应的解释器对象，在创建抽象语法树的时候使用这个新的解释器对象就可以了。
缺点：
不适合复杂的语法
如果语法特别复杂，构建解释器模式需要的抽象语法树的工作是非常艰巨的，再加上有可能会需要构建多个抽象语法树。所以解释器模式不太适合复杂的语法。使用语法分析程序或编译器生成器可能会更好一些。
何时使用？
当有一个语言需要解释执行，并且可以将该语言中的句子表示为一个抽象语法树的时候，可以考虑使用解释器模式。
在使用解释器模式的时候，还有两个特点需要考虑，一个是语法相对应该比较简单，太负责的语法不适合使用解释器模式玲玲一个是效率要求不是很高，对效率要求很高的，不适合使用。
前面介绍了如何获取单个元素的值和单个元素属性的值，下面来看看如何获取多个元素的值，还有多个元素中相拥名称的值,还有前面的测试都是人工组合好的抽象语法树，我们也顺便实现以下简单的解析器，把符合前面定义的语法的表达式，转换成为前面实现的解释器的抽象语法树： 我就直接把代码贴出来了：
复制代码 代码如下:
// 读取多个元素或属性的值
(function () {
/**
* 上下文，用来包含解释器需要的一些全局信息
* @param {String} filePathName [需要读取的xml的路径和名字]
*/
function Context(filePathName) {
// 上一个被处理的多个元素
this.preEles = [];
// xml的Document对象
this.document = XmlUtil.getRoot(filePathName);
}
Context.prototype = {
// 重新初始化上下文
reInit: function () {
this.preEles = [];
},
/**
* 各个Expression公共使用的方法
* 根据父元素和当前元素的名称来获取当前元素
* @param {Element} pEle [父元素]
* @param {String} eleName [当前元素名称]
* @return {Element|null} [找到的当前元素]
*/
getNowEles: function (pEle, eleName) {
var elements = [];
var tempNodeList = pEle.childNodes;
var nowEle;