设计模式——2_4 中介者（Mediator）

我寄愁心与明月，随风直到夜郎西

——李白《闻王昌龄左迁龙标遥有此寄》

定义

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

图纸

一个例子：怎么调度一组地铁

地铁，就是那种在地底下（也未必，深圳的11号线就能看海，听说重庆的地铁还能过楼？）沿着轨道跑的列车

一般来说一个车站会有两个不同方向的站台，而同一个方向的站台在同一时间显然只能有一部列车可以同时出现

那么当一列地铁即将到达某一个站台的时候，是需要确认目标站台上有没有地铁正在停靠的

当你把上述行为抽象成代码的时候，中介者可以帮助你优雅的实现对地铁进行调度的过程，而这正是我们这次的例子：

站台和地铁

无论如何，站台和地铁都一定有对应自己的类，就像这样：

/*** 站台*/
public class Platform {/*** 站台名称*/private String name;/*** 当前停靠的地铁*/private Subway subway;public Platform(String name) {this.name = name;}/*** 进站*/public synchronized void in(Subway subway) {System.out.printf("%s 即将进入 %s%n", subway.getCode(), name);this.subway = subway;System.out.printf("%s 进入了 %s%n", subway.getCode(), name);}/*** 进站*/public synchronized void out() {System.out.printf("%s 离开 %s%n", subway.getCode(), name);this.subway = null;}/*** 是否是空站*/public synchronized boolean isEmpty() {return subway == null;}
}/*** 地铁*/
public class Subway {private String code;public Subway(String code) {this.code = code;}public String getCode() {return code;}
}

我们新建了 Platform（站台） 和 Subway（地铁） 两个类分别用于表示站台和地铁，站台上可以停靠地铁，而且通过 isEmpty 方法可以告诉 client 当前这个站台是否停靠了地铁

接着问题来了，client代码 要怎么指挥 Subway(地铁) 往前走呢？

开车

打个比方，现在我们有 站台A/B/C，有电灯号和灯笼号两部地铁，同时规定：

1. 两部地铁都是沿着A->B->C这个方向往前移动

2. 电灯号从站台A出发，灯笼号从站台B出发

首先我们要初始化他，就像这样：

Platform a = new Platform("A");
Platform b = new Platform("B");
Platform c = new Platform("C");Subway subway_1 = new Subway("电灯号");
Subway subway_2 = new Subway("灯笼号");

接着我们让电灯号进入A站台，再让灯笼号进入A站台；这时候因为电灯号还在站台里，所以程序应该提示我 不能进入。接着让灯笼号离开A站台，再让电灯号进入，就像这样：

private static Map<Subway, Integer> subwayMap = new HashMap<>();//用于记录地铁的位置
private static Platform[] ps;public static void main(String[] args) {//初始化ps = new Platform[]{new Platform("A"), new Platform("B"), new Platform("C")};Subway subway_1 = new Subway("电灯号");Subway subway_2 = new Subway("灯笼号");subwayMap.put(subway_1, 0);ps[0].in(subway_1);subwayMap.put(subway_2, 1);ps[1].in(subway_2);move(subway_1);//电灯号往前走，被挡住move(subway_2);//灯笼号往前走move(subway_1);//电灯号往前走
}public static void move(Subway subway) {Integer position = subwayMap.get(subway);int nextPosition = position + 1 < ps.length ? position + 1 : 0;if (ps[nextPosition].isEmpty()) {//空站台可以驶入ps[position].out();//驶出ps[nextPosition].in(subway);//驶入subwayMap.put(subway, nextPosition);} else {System.out.println("还有车，无法驶入");}
}

这段代码有两个问题：

1. 里面出现了可以抽离出来的部分，也就是move方法

2. 我们向 client 暴露了站台的内部结构，在实战中，你一定不希望这种事的发生

事实上这两个问题都可以通过创建一个平台来解决。于是乎，为了解决这样的问题，我们引入了 指挥中心 的概念

指挥中心

就像这样：

/*** 指挥中心*/
public class ControlCenter {private Map<Subway, Integer> subwayMap = new HashMap<>();//用于记录地铁的位置private Platform[] ps = new Platform[]{new Platform("A"), new Platform("B"), new Platform("C")};/*** 推动某部地铁往前走*/public void move(Subway subway) {Integer position = subwayMap.get(subway);int nextPosition = position + 1 < ps.length ? position + 1 : 0;if (ps[nextPosition].isEmpty()) {//空站台可以驶入ps[position].out();//驶出ps[nextPosition].in(subway);//驶入subwayMap.put(subway, nextPosition);} else {System.out.println("还有车，无法驶入");}}public void addSubway(Subway subway, int position) {subwayMap.put(subway, position);ps[position].in(subway);}
}

 public static void main(String[] args) {ControlCenter controlCenter = new ControlCenter();Subway s1 = new Subway("电灯号");Subway s2 = new Subway("灯笼号");controlCenter.addSubway(s1,0);controlCenter.addSubway(s2,1);controlCenter.move(s1);//电灯号往前走，被挡住controlCenter.move(s2);//灯笼号往前走controlCenter.move(s1);//电灯号往前走}

我们把上面所说的内容抽象到了 ControlCenter（控制中心） 中，让 Subway 对于 Platform 有关的变动不要自己去操作，而是让 ControlCenter 代劳，从而实现对内容和关系的隐藏，以及集中化管理

而这正是一个标准的中介者实现

可能这个例子过于简单，没能把中介者的威力完全体现。事实上在实际开发中，当你的某个局部内的各个组件之间关联非常密切的时候，中介者的存在是不可或缺的。他让你可以从上层俯瞰所有组件之间的结构，而不是在各个组件中去找某个动作实现后会对谁造成影响

碎碎念

中介者和表单

表单，应该是程序设计历史上第一种人机交互方式，也是最常用的交互形式

而表单中的内容通常会有很多级联操作，比如说：

• 密码框和重复密码框，如果两者输入不一致，我应该提示用户吧
• 级联下拉框，选择第一级后，后面的下拉框里的内容需要被修改吧
• 点击重置按钮，已经填的所有信息都应该被清空吧

问题在于，类似这些 在一个控件中，对另一个或几个控件进行操作的业务代码，应该写到哪里去呢？

第一个思路 就是让对象间自己进行交互，那显然不现实。这就意味着一个 重置 按钮对象 必须要获得当前表单内所有控件的引用，那我还怎么复用他？他的逻辑会变得很复杂，因为不同的控件会有不同的重置方式，甚至相同控件在不同的状态下也有不同的重置方式

更优解 其实就是中介者，而且这个中介者很好找，表单自身对象就可以来做这个中介者。可以让表单内的所有对象都来和这个表单对象进行交互，比如说：

• 密码框和重复密码框输入完后发送信息给表单对象通知他验证
• 选择第一级级联下拉框后通知表单对象变化下一级级联下拉框
• 点击重置按钮后，通知表单对象重置表单数据

至此，表单内主体变化对象和被驱动变化的表单对象之间的耦合被解除了，因为只有表单对象需要知道每个操作到底涉及到了多少控件

平台思想

几乎所有的设计模式出现的初衷都是为了降低对象之间的耦合。我们一直讲代码要高内聚、低耦合，高耦合就意味着难以维护，好像一切都是耦合的罪过。既然如此，那我们不禁要问：

​ 耦合可以被消灭吗？

答案是否定的，因为一定程度的耦合是必须的。对象是不可能完全独立、不依赖任何其他对象的。一点耦合都没有的代码，什么事情都完成不了

可是在实践中我们发现，具体对象之间的关联会让我们的系统结构变得复杂（如果画图的话，画出来的效果就像是一个纵横交错的网）

在我们维护系统的时候，尝试勾连出这样子的网的时候，这会让我们死很多脑细胞

所以作为一个热爱生命的人，我们引入了平台思想，让N个相互之间存在关联的对象，尽可能都和同一个对象打交道，然后在这个平台里集中处理一些关联信息，亦或是分发信息

这种设计思路非常非常非常的常见，无论是之前文章里出现过的 工厂方法(Factory Method)、抑或是外观(Facade)，又或者是之后会出现的访问者(Visitor) 都涉及到了这种思想，同时这种思想还是IOC框架实现的基础

但是这种平台便利性是要付出代价的

随着系统的扩大，这个负责对象交互的平台一定会愈发复杂，而这部分 复杂 其实就是原本各自对象之间要进行的交互。也就是说，使用平台并不是彻底消灭了 复杂，而是把他们集中起来处理

这是符合设计原则的，因为其中有一条是这样写的：

变化隔离原则

找出应用中可能需要变化的地方，把他们独立出来，不要和那些不需要变化的代码混合在一起

依据这个原则，所以我们把对象之间的交互和对象自身要处理的业务进行隔离。因为对象之间的交互总是充满不确定性的，而对象自身的业务通常是在编码时就已经确定的

姑妄言之

说白了，中介者其实就是一个跟所有人都有关联的对象。那其实我们的古人早就提到过中介者这样的概念，那时的中介者，通常是我们头顶的月亮。李白就写过：我寄愁心与明月，随风直到夜郎西 这样的诗句，其实就是让大家都共享的月亮帮他传递信息嘛。

所以哪怕人真的是孤岛，又怎么可能真的那么孤单。只要仰望夜空，就一定有人此时此刻和你一起在同一片星空下仰望同一个月亮

万分感谢您看完这篇文章，如果您喜欢这篇文章，欢迎点赞、收藏。还可以通过专栏，查看更多与【设计模式】有关的内容