C++(设计模式):19---行为型模式之解释器模式（Interpreter）

行为型模式概述

• 行为模式涉及到算法和对象间职责的分配。行为模式不仅描述对象或类的模式，还描述它们之间的通信模式。这些模式刻划了在运行时难以跟踪的复杂的控制流。它们将你的注意 力从控制流转移到对象间的联系方式上来
• 行为类模式使用继承机制在类间分派行为。其中包括两个这样的模式：
  • 其中TemplateMethod较为简单和常用。模板方法是一个算法的抽象定义，它逐步地定义该算法， 每一步调用一个抽象操作或一个原语操作，子类定义抽象操作以具体实现该算法
  • 另一种行为类模式是Interpreter。它将一个文法表示为一个类层次，并实现一个解释器作为这些类的实例上的一个操作
• 行为对象模式使用对象复合而不是继承。一些行为对象模式描述了一组对等的对象怎样 相互协作以完成其中任一个对象都无法单独完成的任务。这里一个重要的问题是对等的对象 如何互相了解对方。对等对象可以保持显式的对对方的引用，但那会增加它们的耦合度。在 极端情况下，每一个对象都要了解所有其他的对象。 Mediator在对等对象间引入一个mediator对象以避免这种情况的出现。mediator提供了松耦合所需的间接性
• Chain of Responsibility提供更松的耦合。它让你通过一条候选对象链隐式的向一个对 象发送请求。根据运行时刻情况任一候选者都可以响应相应的请求。候选者的数目是任意的， 你可以在运行时刻决定哪些候选者参与到链中
• Observer模式定义并保持对象间的依赖关系。典型的Observer的例子是Smalltalk中的模型/视图/控制器，其中一旦模型的状态发生变化，模型的所有视图都会得到通知
• 其他的行为对象模式常将行为封装在一个对象中并将请求指派给它：
  • Strategy模式将 算法封装在对象中，这样可以方便地指定和改变一个对象所使用的算法
  • Command模式 将请求封装在对象中，这样它就可作为参数来传递，也可以被存储在历史列表里，或者以其 他方式使用
  • State模式封装一个对象的状态，使得当这个对象的状态对象变化时，该对象可改变它的行为
  • Visitor封装分布于多个类之间的行为
  • 而Iterator则抽象了访问 和遍历一个集合中的对象的方式
• 行为型模式有：
  • Chain of Responsibility（职责链）——对象行为型模式：https://blog.csdn.net/qq_41453285/article/details/106201661
  • Command（命令）——对象行为型模式：https://blog.csdn.net/qq_41453285/article/details/106242934
  • Interpreter（解释器）——类行为型模式：本文介绍
  • Iterator（迭代器）——对象行为型模式：https://blog.csdn.net/qq_41453285/article/details/106242970
  • Mediator（中介者）——对象行为型模式：https://blog.csdn.net/qq_41453285/article/details/106242982
  • Memento（备忘录）——对象行为型模式：https://blog.csdn.net/qq_41453285/article/details/106242996
  • Observer（观察者）——对象行为型模式：https://blog.csdn.net/qq_41453285/article/details/106201675
  • State（状态）——对象行为型模式：https://blog.csdn.net/qq_41453285/article/details/106243009
  • Strategy（策略）——对象行为型模式：https://blog.csdn.net/qq_41453285/article/details/106243021
  • Template Method（模板方法）——类行为型模式：https://blog.csdn.net/qq_41453285/article/details/106243031
  • Visitor（访问者）——对象行为型模式：https://blog.csdn.net/qq_41453285/article/details/106243048

一、意图

• 给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示 来解释语言中的句子

二、动机

• 如果一种特定类型的问题发生的频率足够高 , 那么可能就值得将该问题的各个实例表述为 一个简单语言中的句子。这样就可以构建一个解释器 , 该解释器通过解释这些句子来解决该问 题

三、适用性

• 当有一个语言需要解释执行 , 并且你可将该语言中的句子表示为一个抽象语法树时，可使 用解释器模式。而当存在以下情况时该模式效果最好：
  • 该文法简单对于复杂的文法 , 文法的类层次变得庞大而无法管理。此时语法分析程序生 成器这样的工具是更好的选择。它们无需构建抽象语法树即可解释表达式 , 这样可以节 省空间而且还可能节省时间
  • 效率不是一个关键问题最高效的解释器通常不是通过直接解释语法分析树实现的 , 而是 首先将它们转换成另一种形式。例如，正则表达式通常被转换成状态机。但即使在这种 情况下, 转换器仍可用解释器模式实现, 该模式仍是有用的。

四、结构

五、参与者

• AbstractExpression（抽象表达式）：声明一个抽象的解释操作，这个接口为抽象语法树中所有的节点所共享
• TerminalExpression（终结符表达式）：
  • 实现与文法中的终结符相 关联的解释操作
  • 一个句子中的每个终结符需要该类的一个实例。
• NonterminalExpression（非终结符表达式）：
  • 对文法中的每一条规则R::= R1 R2 . . . Rn都需要一个NonterminalExpression类
  • 为从R1到Rn的每个符号都维护一个AbstractExpression类型的实例变量
  • 为文法中的非终结符实现解释（Interpret ）操作。解释（Interpret ）一般要递归地调用表示 R1到Rn的那些对象的解释操作
• Context（上下文）：包含解释器之外的一些全局信息
• Client（客户） ：
  • 构建(或被给定) 表示该文法定义的语言中一个特定的句子的抽象语法树。该抽象语 法树由NonterminalExpression和TerminalExpression的实例装配而成
  • 调用解释操作

六、协作

• Client构建(或被给定)一个句子，它是NonterminalExpression和TerminalExpression的实例的一个抽象语法树. 然后初始化上下文并调用解释操作
• 每一非终结符表达式节点定义相应子表达式的解释操作。而各终结符表达式的解释操作 构成了递归的基础
• 每一节点的解释操作用上下文来存储和访问解释器的状态

七、效果

• 待续（学习到的时候再回来补）

八、实现

• 待续（学习到的时候再回来补）

九、代码示例

• 待续（学习到的时候再回来补）

十、相关模式

• Composite模式: 抽象语法树是一个复合模式的实例
• Flyweight模式：说明了如何在抽象语法树中共享终结符
• Iterator：解释器可用一个迭代器遍历该结构
• Visitor：可用来在一个类中维护抽象语法树中的各节点的行为