解释器模式和调停者模式都是行为型模式，由于二者用的情形比较少，不作过多解读，介绍一下相关概念，以作参考。
解释器模式有点儿“编译器”的概念，像个超级简单的编译器，且跟硬件无关，它的目的是定义语言（使用规定格式和语法的代码）的文法，然后建立一个解释器来解释该语言中的句子。
在 GOF 的书中指出：如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题。而且当文法简单、效率不是关键问题的时候效果最好——这也就是解释器模式适用的环境。
放张解释器结构类图吧，作为参考，此处不作更深入的解读了。
调停者模式定义为用一个调停对象来封装一系列的对象交互。调停者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互简单点来说，将原来两个直接引用或者依赖的对象拆开，在中间加入一个“调停”对象，使得两头的对象分别和“调停”对象引用或者依赖。当然并不是所有的对象都需要加入“调停”对象。如果对象之间的关系原本一目了然，调停对象的加入便是“画蛇添足”。
来看下调停者模式的组成部分吧。
1) 抽象调停者（Mediator）角色：抽象调停者角色定义统一的接口用于各同事角色之间的通信。
2) 具体调停者（Concrete Mediator）角色：具体调停者角色通过协调各同事角色实现协作行为。为此它要知道并引用各个同事角色。
3) 同事（Colleague）角色：每一个同事角色都知道对应的具体调停者角色，而且与其他的同事角色通信的时候，一定要通过调停者角色协作。
来自《设计模式》一书的类图：
是否还记得应用广泛的 MVC 分为哪三层？模型层（Model）、表现层（View）还有控制层（Control\Mediator）。控制层便是位于表现层与模型层之间的调停者。笼统地说MVC 也算是调停者模式在框架设计中的一个应用。