前言
解释器模式是23种设计模式的最后一个设计模式，要讲清楚解释器模式，我们分两个部分来理解，本篇是第一部分先理解它目前的应用场景，然后再理解它的原理。
为了帮助理解解释器模式，我们先来谈谈编译原理上说的编译器，编译器分为几个部分组成，比如：
- 词法分析器
- 语法分析器
- 语义分析器
- 中间代码优化器
- 最终的代码生成器
而这个解释器其实就是完成了对语法的解析，将一个个的词组解释成了一个个语法范畴，之后拿来使用而已。
解释器和编译器
关于编译器与解释器我们先来看两张图，如下图所示：
编译器
解释器
用解释器很方便，只需要直接“运行”就好了，不用像C那样有编译链接的工序。
为什么说这些语言是跨平台的？因为你写了程序以后，如果这个平台上有这种语言的解释器，只需要拿到这个平台上直接运行就可以了。你可以理解为：解释器是在“一边编译，一边运行”，它只是把以前程序员手工做的编译过程放在了运行程序的时候进行。
为什么我们一般说解释器的效率比较低？你也可以想象的是，一段程序在解释器中运行时可能会被编译多次，因为每次运行到这段程序时，都会重新编译一次，这样的开销是很大的。
所以诞生了Java，C#这样的预编译语言：
在运行之前，需要手动把源代码编译成中间代码（Java里叫字节码），然后在解释器中执行。这种架构避免了上面纯解释器中编译源代码的开销，所以相对会有效率一些。
其实像Python，Perl，PHP可能都不会是真的纯解释执行的，这样实在是太没有效率。Python在运行时会生成pyc的二进制临时文件，看起来很像是预编译的结果。不过JavaScript这种语言确实是纯解释执行的，因为它一般不会写得太长。