17. 接口隔离——中介者模式

“接口隔离” 模式

• 在组织构建过程中，某些接口之间的直接依赖常常会带来很多问题、甚至根本无法实现。采用添加一层间接（稳定）接口，来隔离本来相互紧密关联的接口是一种常见的解决方案。
• 典型模式
  • Facade
  • Proxy
  • Adapter
  • Mediator

一、动机

​ 面向对象设计鼓励将行为分布到各个对象中。这种分布可能会导致对象间有许多连接。在最坏的情况下，每一个对象都知道其他对象。

​ 虽然将一个系统分割成许多对象通常可以增强可复用性，但是对象间相互连接的激增又会降低其可复用性。大量的相互连接使得一个对象似乎不太可能在没有其他对象的支持下工作——系统表现为一个不可分割的整体。而且，对系统的行为进行任何较大的改动都十分困难，因为行为被分不到许多对象中。

二、场景分析

​ 例如，考虑一个图形用户界面中对话框的实现。对话框使用一个窗口来展现一系列的窗口组件，如按钮、菜单和输入域等，如下图所示：

​ 通常对话框中的窗口组件间存在依赖关系。例如，当一个特定的输入域为空时，某个按钮不能使用；在称为列表框的一系列选项中选择一个表目可能会改变一个输入域的内容；反过来，在输入域中输入正文可能会自动的选择一个或多个列表框中相应的表目；一旦正文出现在输入域中，其他一些按钮可能就变得能够使用了，这些按钮允许用户做一些操作，比如改变或删除这些正文所指的东西。

​ **不同的对话框会有不同的窗口组件间的依赖关系，因此即使对话框现实相同类型的窗口组件，也不能简单地直接重用已有的窗口组件类；**而必须定制它们以反映特定对话框的依赖关系。

​ 为了解决这个问题，我们可以通过将集体行为封装在一个单独的中介者对象中，中介者负责控制和协调一组对象间的交互。中介者充当一个中介以使组中的对象不再相互显示引用。这些对象仅知道中介者，从而减少了相互连接的数目。

​ 例如，FontDialogDirector可作为一个对话框中的窗口组件间的中介者。FontDialogDirector对象知道对话框中的各窗口组件，并协调它们之间的交互，它充当窗口组件间通信的中转中心，如下图所示：

​ 下面的交互图说明了各对象如何协作处理一个列表框中选项的变化。

​ 一个列表框的选择被传入到一个输入域的事件变化如下：

1. 列表框告诉它的操作者被改变了；
2. 操作者从列表框中得到选项中的选择项；
3. 操作者将该选择项传递给入口域；
4. 现在入口域已有正文，操作者使得用于发起一个动作（如设置 字体）的按钮可用

具体实现的类图如下：

三、模式定义

​ 用一个中介对象来封装一些列对象的交互。中介者使得个对象不需要显示地互相引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。

类图：

优点：

1. **减少了子类生成。**中介者将原本分布于多个对象间的行为集中在一起。改变这些行为只需生成Meditator的子类即可。这样各个Colleague类可被复用
2. **它将各Colleague解耦。**Mediator有利于各Colleague间的松耦合，你可以独立改变和复用各Colleague类和Mediator类
3. **它简化了对象协议。**用Mediator和各Colleague间的一对多的交互来代替多对多的交互。一对多的关系更易于理解、维护和扩展。
4. **它对对象如何写作进行了抽象。**将中介作为一个独立的概念并将其封装在一个对象中，使你将注意力从对象各自本身的行为转移到它们的交互上来。这有助于弄清楚一个系统中的对象是如何交互的。

缺点：

1. **它使控制集中化。**中介模式将交互复杂性变为中介者的复杂性。因为终结者封装了协议，它可能变得比任一个Colleague都复杂。这可能是中介者自身成为一个难于维护的庞然大物。

四、要点总结

• 随着控制逻辑的复杂化，Mediator具体对象的实现可能相当复杂，这时候可以对Mediator对象进行分解处理。
• Facade模式是解藕系统间（单向）的对象关联关系；Mediator模式是解藕系统内各个对象（双向）的关联关系。