面向对象的程序设计中,我们通常将功能进行分解,按照职责以类为维度进行划分,也就是使用时功能最终将分布在多个对象中
并且我们会尽可能的保持对象功能的单一(单一职责原则)
相对于对象的单一职责来说,任何的系统或者模块的功能却并不会单一,往往都是有多个对象交互协作来实现所有的功能
对象之间不可避免的需要建立连接
换句话说
系统(或者某模块)必然是复杂的(没有什么系统可以几个对象就轻松搞定,那样或许也不能称之为系统了吧)
功能必然会分布在多个对象中
多个对象协作必然需要联系,这必然导致耦合的产生
如上图所示,虽然系统对外呈现是一个统一的整体,但是,内部各个模块之间很可能是紧密的耦合
各个模块相互联系,可能互相持有引用,会出现网状结构,完全不符合迪米特法则。
如果对系统进行改动,将会变得困难。
我们以装修为例
一般装修公司都会给每一个项目配备一个项目经理(这个项目也就是你家这个单子了,项目经理就是包工头)
装修的一般阶段分为:前期设计→拆改→水电→瓦工→木工→油漆→安装→保洁→软装
项目经理手上经常同时有几个工地在同步进行,只要错的开就好了
因为每个阶段都是有先后顺序的,你不可能先木工,然后再去拆改;
因为每个阶段也都需要一定时间,也意味着这一拨人不可能同时在你家工作
开工后项目经理会进行工作安排
水电工结束了A之后,项目经理会安排他到B,然后安排瓦工到A,然后........
所有的顺序都是由项目经理负责调度,水电工可以完全不认识瓦工,他们也完全不需要进行联系
有事儿找项目经理
如果没有项目经理,会是什么场景?
那就是人人都是项目经理,人人都需要管自己,还需要管别人
也就是每个人安排分配自己的时间与任务
水电工结束后需要联系瓦工进场,如果瓦工发现有遗留问题,需要联系水电工进行沟通
木工需要联系瓦工确认进展情况,油漆工又需要确认木工状况...
你会发现他们必须要经常保持联系,以获得进展情况,进而安排自己的工作
一个包工队尚且如此,如果是一个大的装修公司,怎么办?
而且装修而言,阶段之间还会有顺序,油漆工用不到联系水电工
但是在系统中,对象岂会仅仅与一个对象联系?
那岂不是更复杂、乱套?
中介者模式就是为了解决系统内部的调度问题,降低系统内部各模块之间的耦合度。
装修公司的项目经理、小组组长、班长,团队leader等其实这都是中介者模式的体现。
有很多书中以“房屋中介”作为中介者模式的一种场景
个人认为对于某一个房东或者租客而言,“房屋中介”的含义是为你服务的中介人员,此时的含义更接近代理模式
而从广义上看,有很多租客、买家,也存在很多房东,“房屋中介”将他们联系在一起,此时的“房租中介”应该是中介公司,这时才更符合中介者模式的含义
中介者模式的重点在于“调度、协调”,含义更接近“指挥中心”,被指挥的是该系统内部的成员
如果在一个系统中对象之间存在多对多的相互关系
我们可以将对象之间的一些交互行为从各个对象中分离出来,并集中封装在一个中介者对象中,并由该中介者进行统一协调
如上图所示,对象之间多对多的复杂关系就转化为相对简单的一对多关系
简化了对象之间的复杂交互
显然,中介者模式是迪米特法则(不要和陌生人说话)的典型。
结构
同事角色Colleague
系统中所有组成部件的抽象角色
具体的同事角色ConcreteColleague
系统的每一个具体的组成部分,就像公司的每个同事
提供自身职责功能的方法接口,供中介者调用
定义中介者到同事对象的接口,也就是提供接口给中介者调用
中介者(项目经理)根据你的技能分配任务,也就是调用你的方法
中介者角色Mediator
定义了同事Colleague对象到中介者的接口,也就是所有同事通信的接口(同事间的通信借助于中介者提供的这个方法)
也就是提供一个方法给同事们调用,用来请求其他同事协助协助,这个方法是中介者提供的
这个方法典型的示例就是事件处理方法
具体的中介者ConcreteMediator
具体的中介者,实现Mediator定义的接口,协调各同事进行协作
所有的成员之间,可以相互协调工作,但是却又不直接相互管理
这些对象都与项目经理“中介者”进行紧密联系
由项目经理进行工作协调,每个组成部分就如同我们项目组中的一个成员,也就是同事一样,这也是上文中Colleague 角色的由来
如何相互协调工作但是却又不直接相互管理?比如
class A{void f(){//do sthB b = new B();b.g();}
上面伪代码中
类A有一个方法f ,做了一些事情之后,创建了一个B的对象b,然后调用b的方法g,做了一些处理
这就是A与B的协作,A也同时具有管理B的职责
如果转换为下面的形式,就是中介者模式
A和B的协作不在具有对象管理关系,而是项目经理Mediator统一进行管理
class Mediator{A a = new A();B b = new B();void cooperation(){a.f();b.g();}}
代码示例
使用《设计模式 可复用面向对象软件的基础》中的例子为原型
考虑一个图形用户界面中对话框的实现。
对话框使用一个窗口来展现一系列的窗口组件,比如按钮菜单输入域等
比如下图,IDEA的字体设置窗口,当进行Font字体设置时
预览区域内的字体将会发生变化
右下角的Apply 应用按钮将成为可点击状态
一种可能的解决方法
package mediator.simple; /*** 设置字体类,提供字体设置方法.* 并且创建展示Display对象,调用reDisplay方法重新展示* 并且创建按钮Button对象,调用applyButton方法使能应用按钮*/public class Font { public void setFont() { System.out.println("设置字体..."); Display display = new Display(); display.reDisplay(); Button button = new Button(); button.applyButton(); }}
package mediator.simple;public class Display {public void reDisplay() { System.out.println("字体重新展示..."); }}
package mediator.simple; public class Button {public void applyButton() { System.out.println("应用按钮可用..."); }}
package mediator.simple;public class Test {public static void main(String[] args) { Font font = new Font(); font.setFont(); }}
上面的示例很简单
为了实现“点击设置字体,选择字体后预览框字体的改变以及使能应用按钮的功能”
也就是联动的功能
设置字体后,分别创建展示和按钮对象,调用对象的方法
很显然,字体不仅操心自己的事情,还管理着展示Display和按钮Button
而且,如果直接点击取消会发生什么?一切将会还原,又伴随着一系列的调用
难道仍旧需要:“不仅操心自己的事情,还要负责管理别人么”?
就像没有项目经理的包工队一样了,既操心自己又要管理别人
成了我们上面所说的网状结构,内部各个同事之间的耦合度极高
重构中介者模式
重构的业务逻辑:
通过引入mediator中介者,作为同事之间协作的中间人,提供operation()方法,用于同事间请求协助、事件处理
每个同事类都知道这个中介,所以在抽象角色Colleague中设置了Mediator属性,构造方法注入,并且提供notifyEvent方法,封装了mediator的operation()方法
当具体的同事ConcreteColleague,执行操作后,需要其他同事协作时,直接调用notifyEvent()方法
每个具体的同事提供自身的职责接口
简单地说就是,提供中介者“项目经理”mediator,提供事件处理方法
所有的同事都只知道“项目经理”,如果有事需要其他同事办,就叫“项目经理”。
Mediator抽象中介者角色定义了operation方法
各个Colleague对象通过此方法进行通信,接受参数类型为Colleague的对象
package mediator;public abstract class Mediator {abstract void operation(Colleague event);}
Colleague抽象同事角色拥有Mediator,通过构造方法注入
提供了notifyEvent方法,调用中介者的operation方法,并且将自身作为参数
package mediator;public abstract class Colleague {private Mediator mediator; Colleague(Mediator mediator) {this.mediator = mediator; }public void notifyEvent() { mediator.operation(this); }}
package mediator;public class Button extends Colleague { Button(Mediator mediator){super(mediator); } public void applyButton() { System.out.println("应用按钮可用..."); }}
package mediator; public class Display extends Colleague { Display(Mediator mediator) {super(mediator); }public void reDisplay() { System.out.println("字体重新展示..."); }}
package mediator; public class Font extends Colleague {private String fontName; public String getFontName() {return fontName; } Font(Mediator mediator) {super(mediator); } public void changeFont() { System.out.println("设置字体......"); fontName = "微软雅黑"; notifyEvent(); }}
ConcreteMediator实现了Mediator定义的接口
并且内部维护三个对象
如果事件类型是Font,那么调用设置字体的事件
package mediator;public class ConcreteMediator extends Mediator {private Button button;private Display display;private Font font; ConcreteMediator() { button = new Button(this); display = new Display(this); font = new Font(this); } @Overridevoid operation(Colleague event) {if (event instanceof Font) { setFontEvent(event); } } private void setFontEvent(Colleague event) { System.out.println(((Font) event).getFontName()); button.applyButton(); display.reDisplay(); }}
测试代码
package mediator; public class Test {public static void main(String[] args){ Mediator mediator = new ConcreteMediator(); Font font = new Font(mediator); font.changeFont(); }}
上面的示例中,以设置字体为例,当字体变化时,请求“项目经理”安排其他同事协助
“项目经理”operation(Colleague event) 发现是设置字体的事件后,调用对应的事件处理方法,也就是寻找其他同事进行协助
中介者模式将每个场景中对象之间的协作进行封装
小结
当你需要其他同事协助时,肯定不需要项目经理每次都创建具体的同事对象
上面的示例中,在ConcreteMediator的构造方法中创建的各个具体同事的实例(可以理解为项目经理手下有你和你的一帮同事)
你还可以提取出来工厂类用于管理同事类和中介者类
比如通过一个工厂对象管理各个同事实例(如果可以还可以将各个同事都设置为单例 )
并且中介者类作为这个工厂对象的内部类
同事对象的传递可以达到信息的获取与回调
通过给Font加了一个fontName属性,通过打印信息可以看得出来
通过将当时发生事件的对象传递了过来,可以获得事件的更多信息,可以根据信息进一步的进行操作
比如,此处的设置了字体,设置了什么字体?这一进一步的信息就通过参数携带进来
而且,这种方式还可以通知到Font本身
也就是可以在setFontEvent(Colleague event) 事件处理中,调用Font的方法进行结果返回,有回调的韵味
良好的扩展性
如果需要增加一个新的事件处理过程,比如点击取消按钮,还原字体设置,还原预览按钮
只需要在Button新增加一个职责(方法),然后在ConcreteMediator中新增加一种类型的事件处理程序即可
上面的示例中仅仅定义了几个简单的方法,实践中每个具体同事角色自然不会仅仅只有几个方法
不管有多少方法,都可以通过中介者将他们的协作逻辑进行封装
通过具体的中介者ConcreteMediator的处理方法进行安排
中介者模式可以很好地应用于事件通知的处理
中介者模式时序图
当某一个同事对象产生事件后,如果需要其他同事进行协助,他将调用中介者的方法
中介者接到消息后,调用其他同事的方法(安排其他同时干活),然后最终还可以将消息进行返回
与门面模式对比
门面模式和中介者模式都是通过中间类降低系统的耦合度
但是门面模式是为了子系统提供一个简单一致的接口,客户端透过门面类向子系统发送消息,可以认为消息的发送是单方向的
客户端--->门面--->子系统方法,子系统提供功能给客户端
门面是在外部客户端和内部子系统之间
中介者模式中,则是主要复杂系统内部多个对象之间的相互协作
中介者是各个内部对象同事之间
扩展
任何模式都不是一成不变的,模式结构图只是一种相对比较合适准确的方案
但是涉及到具体的业务中,一切都是可变的
中介者模式也有多种灵活性
如果只有一个中介者对象,显然抽象Mediator角色是可以隐藏的
那么ConcreteMediator就兼顾了这个角色,提供通信接口给同事角色
中介者模式的本质含义是负责协调系统内部的多个交互的对象,将同事进行解耦
也就是说实现共同的接口并不是必须的
而实际上,一个系统中协作的多个对象,很可能是不同的类型,如果去掉了抽象角色Colleague
那么就可以将任意的有关联的对象组织在一起,通过中介者协同工作
而且,也并不意味着一定要中介者持有同事角色,如果合适,直接创建中介者也并非不可以
虽然上面提到你可以使用另外的工厂管理,那也只是一种常用用法而已。
只需要记住中介者的本质在于“行为与协作的分离,中介者封装了对象间的协作”
总结
中介者模式将对象的行为和协作进行分离,使对象更加专注于对象的行为,也就是自身的功能
将协作分离出来封装到中介者内部
迪米特法则,不要和陌生人讲话,只与你的朋友通信,中介者模式是迪米特法则的典型应用
通过引入中介者对象,在同事之间的请求调用中,增加了“项目经理”,如果有事搞不定,需要协助,那么就找他
每个人只和项目经理对话,也就是仅仅和项目经理这个朋友聊天,其他的同事都不理了  ̄□ ̄||
中介者将网状结构,转换为了星型结构
将多对多的关系,转换为了一对多的关系
所以中介者模式将系统中对象对其他对象的引用数目降到最低,简化了对象之间的交互。
中介者模式将各个同事对象之间进行解耦,增加新的中介者或者同事都比较方便,符合开闭原则
MVC模式,也是一种典型的中介者模式,控制器负责视图层和模型层的调度处理,是一个明显的中介者。
中介者模式将同事进行解耦,但是各个Colleague类必须同中介者进行交互
更准确的说,解耦后的关系植入到了中介者自身,如果原来的同事对象间的相互调用非常复杂
那么,这个中介者也很可能非常的复杂难以维护
换言之,同事间的复杂性与耦合性转移到了中介者内部
中介者内部对于各个同事之间的协调代码不太可能复用,所以具体同事类的复用性也是以中介者的不可复用为代价的
如果系统中的各个对象之间存在复杂的引用关系,希望能够通过中间类将他们进行解耦
或者系统中对象间的引用混乱,交互太多,导致难以进行类的复用
你就可以考虑中介者模式
但是并不意味着任何涉及到多个类交互的地方都用中介者模式,如果原本并不复杂,使用中介者将会增加复杂度
基本前提就是紧密耦合,比如出现了网状结构