首先 我们需要理解一点：什么是架构模式呢？
架构模式是一个通用的、可重用的解决方案，用于在给定上下文中的软件体系结构中经常出现的问题。架构模式与软件设计模式类似，但具有更广泛的范围。
那么 什么是解释器模式呢？
这个模式用于设计一个解释用专用语言编写的程序的组件。它主要指定如何评估程序的行数，即以特定的语言编写的句子或表达式。其基本思想是为每种语言的符号都有一个分类。
一、 模式定义
所谓解释器模式就是定义语言的文法，并且建立一个解释器来解释该语言中的句子。
什么？不明白？
说的简单点，就是：给定一个语言，然后定义它的文法，并定义一个解释器，该解释器用该文法来解释语言中的句子。
在这里 ，如果你学过软件构造相关只是的话，相信已经理解了个七七八八。
二、使用场景
如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子.这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题.
举个例子：
数据库查询语言中的SQL语句。你只需要输入相应select语句，解释器便会分析SQL语句的文法，识别你想要找到的数据元素并把它提取出来。
解释器模式主要包含如下几个角色：
AbstractExpression: 抽象表达式。声明一个抽象的解释操作，该接口为抽象语法树中所有的节点共享。
TerminalExpression: 终结符表达式。实现与文法中的终结符相关的解释操作。实现抽象表达式中所要求的方法。文法中每一个终结符都有一个具体的终结表达式与之相对应。
NonterminalExpression: 非终结符表达式。为文法中的非终结符相关的解释操作。
Context: 环境类。包含解释器之外的一些全局信息。
Client: 客户类
优点： 1、 可扩展性比较好，灵活。 2、 增加了新的解释表达式的方式 3、 易于实现简单文法。
缺点： 可利用场景比较少
2、 对于复杂的文法比较难维护。3、解释器模式会引起类膨胀 4、解释器模式采用递归调用方法
使用场景：1、可以将一个需要解释执行的语言中的句子表示为一个抽象语法树 2、一些重复出现的问题可以用一种简单的语言来进行表达 3、一个简单语法需要解释的场景
三、模式总结：
1、在解释器模式中由于语法是由很多类表示的，所以可扩展性强。
2、虽然解释器的可扩展性强，但是如果语法规则的数目太大的时候，该模式可能就会变得异常复杂。所以解释器模式适用于文法较为简单的。
3、解释器模式可以处理脚本语言和编程语言。常用于解决某一特定类型的问题频繁发生情况。
PS：本次博客是LZ吸收多位博主分享的经验总结而成 侵删。