中介者模式调停者 Mediator 行为型设计模式（二十一）

中介者模式（Mediator）

调度、调停

意图

用一个中介对象（中介者）来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散

而且可以独立地改变它们之间的交互。

中介者模式又称为调停者模式。

面向对象的程序设计中，我们通常将功能进行分解，按照职责以类为维度进行划分，也就是使用时功能最终将分布在多个对象中

并且我们会尽可能的保持对象功能的单一（单一职责原则）

相对于对象的单一职责来说，任何的系统或者模块的功能却并不会单一，往往都是有多个对象交互协作来实现所有的功能

对象之间不可避免的需要建立连接

换句话说

系统（或者某模块）必然是复杂的（没有什么系统可以几个对象就轻松搞定，那样或许也不能称之为系统了吧）

功能必然会分布在多个对象中

多个对象协作必然需要联系，这必然导致耦合的产生

如上图所示，虽然系统对外呈现是一个统一的整体，但是，内部各个模块之间很可能是紧密的耦合

各个模块相互联系，可能互相持有引用，会出现网状结构，完全不符合迪米特法则。

如果对系统进行改动，将会变得困难。

我们以装修为例

一般装修公司都会给每一个项目配备一个项目经理（这个项目也就是你家这个单子了，项目经理就是包工头）

装修的一般阶段分为：前期设计→拆改→水电→瓦工→木工→油漆→安装→保洁→软装

项目经理手上经常同时有几个工地在同步进行，只要错的开就好了

因为每个阶段都是有先后顺序的，你不可能先木工，然后再去拆改；

因为每个阶段也都需要一定时间，也意味着这一拨人不可能同时在你家工作

开工后项目经理会进行工作安排

水电工结束了A之后，项目经理会安排他到B，然后安排瓦工到A，然后........

所有的顺序都是由项目经理负责调度，水电工可以完全不认识瓦工，他们也完全不需要进行联系

有事儿找项目经理

如果没有项目经理，会是什么场景？

那就是人人都是项目经理，人人都需要管自己，还需要管别人

也就是每个人安排分配自己的时间与任务

水电工结束后需要联系瓦工进场，如果瓦工发现有遗留问题，需要联系水电工进行沟通

木工需要联系瓦工确认进展情况，油漆工又需要确认木工状况...

你会发现他们必须要经常保持联系，以获得进展情况，进而安排自己的工作

一个包工队尚且如此，如果是一个大的装修公司，怎么办？

而且装修而言，阶段之间还会有顺序，油漆工用不到联系水电工

但是在系统中，对象岂会仅仅与一个对象联系？

那岂不是更复杂、乱套？

中介者模式就是为了解决系统内部的调度问题，降低系统内部各模块之间的耦合度。

装修公司的项目经理、小组组长、班长，团队leader等其实这都是中介者模式的体现。

有很多书中以“房屋中介”作为中介者模式的一种场景

个人认为对于某一个房东或者租客而言，“房屋中介”的含义是为你服务的中介人员，此时的含义更接近代理模式

而从广义上看，有很多租客、买家，也存在很多房东，“房屋中介”将他们联系在一起，此时的“房租中介”应该是中介公司，这时才更符合中介者模式的含义

中介者模式的重点在于“调度、协调”，含义更接近“指挥中心”，被指挥的是该系统内部的成员

如果在一个系统中对象之间存在多对多的相互关系

我们可以将对象之间的一些交互行为从各个对象中分离出来，并集中封装在一个中介者对象中，并由该中介者进行统一协调

如上图所示，对象之间多对多的复杂关系就转化为相对简单的一对多关系

简化了对象之间的复杂交互

显然，中介者模式是迪米特法则（不要和陌生人说话）的典型。

结构

同事角色Colleague

系统中所有组成部件的抽象角色

具体的同事角色ConcreteColleague

系统的每一个具体的组成部分，就像公司的每个同事

提供自身职责功能的方法接口，供中介者调用

定义中介者到同事对象的接口，也就是提供接口给中介者调用

中介者（项目经理）根据你的技能分配任务，也就是调用你的方法

中介者角色Mediator

定义了同事Colleague对象到中介者的接口，也就是所有同事通信的接口（同事间的通信借助于中介者提供的这个方法）

也就是提供一个方法给同事们调用，用来请求其他同事协助协助，这个方法是中介者提供的

这个方法典型的示例就是事件处理方法

具体的中介者ConcreteMediator

具体的中介者，实现Mediator定义的接口，协调各同事进行协作

所有的成员之间，可以相互协调工作，但是却又不直接相互管理

这些对象都与项目经理“中介者”进行紧密联系

由项目经理进行工作协调，每个组成部分就如同我们项目组中的一个成员，也就是同事一样，这也是上文中Colleague 角色的由来

如何相互协调工作但是却又不直接相互管理？比如

class A{
void f(){
//do sth
B 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类必须同中介者进行交互

更准确的说，解耦后的关系植入到了中介者自身，如果原来的同事对象间的相互调用非常复杂

那么，这个中介者也很可能非常的复杂难以维护

换言之，同事间的复杂性与耦合性转移到了中介者内部

中介者内部对于各个同事之间的协调代码不太可能复用，所以具体同事类的复用性也是以中介者的不可复用为代价的

如果系统中的各个对象之间存在复杂的引用关系，希望能够通过中间类将他们进行解耦

或者系统中对象间的引用混乱，交互太多，导致难以进行类的复用

你就可以考虑中介者模式

但是并不意味着任何涉及到多个类交互的地方都用中介者模式，如果原本并不复杂，使用中介者将会增加复杂度

基本前提就是紧密耦合，比如出现了网状结构

原文地址:中介者模式调停者 Mediator 行为型设计模式（二十一）

转载于:https://www.cnblogs.com/noteless/p/10130616.html