简介
为什么要使用解释器模式
在软件设计时，如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题。
什么是解释器模式
解释器模式(Interpreter Pattern)：给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
类型
类行为型模式
使用频率
★☆☆☆☆
学习难度
★★★★★
角色
角色
- AbstractExpression：抽象表达式
- 抽象类
- 声明了抽象的解释操作。
- 它是所有终结符表达式和非终结符表达式的公共父类。
- TerminalExpression：终结符表达式
- 具体类
- 终结符表达式是抽象表达式的子类。
- 实现了与文法中的终结符相关联的解释操作。
- 在句子中的每一个终结符都是该类的一个实例。
- NonterminalExpression：非终结符表达式
- 具体类
- 非终结符表达式也是抽象表达式的子类。
- 实现了文法中非终结符的解释操作。
- 由于在非终结符表达式中可以包含终结符表达式，也可以继续包含非终结符表达式，因此其解释操作一般通过递归的方式来完成。
- Context：上下文
- 存储解释器之外的一些全局信息。
UML类图
优缺点
优点
- 易于改变和扩展文法。由于在解释器模式中使用类来表示语言的文法规则，因此可以通过继承等机制来改变或扩展文法。已有的表达式可以被增量式地改变，新的表达式可以定义为旧的表达式的变体。
- 易于实现文法。在抽象语法树中各个表达式节点类的实现都是相似的，这些类的代码一般易于编写，通常也可以通过一些工具自动生成节点类代码。
- 符合“开闭原则”。增加新的解释表达式较为方便。如果需要增加新的解释表达式，只需要对应增加一个新的终结符表达式或非终结符表达式类，原有表达式类代码无须修改。
缺点
- 复杂的文法难以维护。解释器模式为文法中的每一条规则至少定义了一个类。因此包含许多规则的文法往往难以维护。当文法复杂时，可以考虑其他的技术如语法分析程序或编译生成器更合适。
适用环境
- 如果一种特定类型的问题发生的频率足够高，而且问题可以通过语言来表达。
- 可以将一个需要解释执行的语言中的句子表示为一个抽象语法树。
- 文法较为简单。
使用场景
- 待补充
扩展
相关模式
- 抽象语法树是组合模式Composite的实例。
- 享元模式Flyweight模式说明了如何在抽象语法树种共享终结符。
- 解释器可用一个迭代器Iterator遍历该结构。
- 访问者模式Visitor可用来在一个类中维护抽象语法树中的个节点的行为。
问题
在软件开发中，你在哪里用到了解释器模式？如何使用它的？
待补充。