我寄愁心与明月,随风直到夜郎西
——李白《闻王昌龄左迁龙标遥有此寄》
文章目录
- 定义
- 图纸
- 一个例子:怎么调度一组地铁
- 站台和地铁
- 开车
- 指挥中心
- 碎碎念
- 中介者和表单
- 平台思想
- 但是这种平台便利性是要付出代价的
- 变化隔离原则
- 姑妄言之
定义
用一个中介者对象来封装一系列的对象交互。中介者使各个对象之间不需要显式的相互引用,从而使其耦合松散,而且可以独立地改变他们之间的交互
图纸
一个例子:怎么调度一组地铁
地铁,就是那种在地底下(也未必,深圳的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,有电灯号和灯笼号两部地铁,同时规定:
-
两部地铁都是沿着A->B->C这个方向往前移动
-
电灯号从站台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("还有车,无法驶入");
}
}
这段代码有两个问题:
-
里面出现了可以抽离出来的部分,也就是move方法
-
我们向 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框架实现的基础
但是这种平台便利性是要付出代价的
随着系统的扩大,这个负责对象交互的平台一定会愈发复杂,而这部分 复杂 其实就是原本各自对象之间要进行的交互。也就是说,使用平台并不是彻底消灭了 复杂,而是把他们集中起来处理
这是符合设计原则的,因为其中有一条是这样写的:
变化隔离原则
找出应用中可能需要变化的地方,把他们独立出来,不要和那些不需要变化的代码混合在一起
依据这个原则,所以我们把对象之间的交互和对象自身要处理的业务进行隔离。因为对象之间的交互总是充满不确定性的,而对象自身的业务通常是在编码时就已经确定的
姑妄言之
说白了,中介者其实就是一个跟所有人都有关联的对象。那其实我们的古人早就提到过中介者这样的概念,那时的中介者,通常是我们头顶的月亮。李白就写过:我寄愁心与明月,随风直到夜郎西 这样的诗句,其实就是让大家都共享的月亮帮他传递信息嘛。
所以哪怕人真的是孤岛,又怎么可能真的那么孤单。只要仰望夜空,就一定有人此时此刻和你一起在同一片星空下仰望同一个月亮
万分感谢您看完这篇文章,如果您喜欢这篇文章,欢迎点赞、收藏。还可以通过专栏,查看更多与【设计模式】有关的内容