请选择 进入手机版 | 继续访问电脑版

[设计模式] 中介者模式 调停者 Mediator 行为型 设计模式(二十一)

计算机科学 计算机科学 3506 人阅读 | 0 人回复

中介者模式(Mediator)

调度、调停

image.png

意图

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

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

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

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

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

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

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

换句话说

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

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

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

image.png

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

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

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

我们以装修为例

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

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

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

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

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

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

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

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

有事儿找项目经理

如果没有项目经理,会是什么场景?

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

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

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

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

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

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

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

但是在系统中,对象岂会仅仅与一个对象联系?

那岂不是更复杂、乱套?


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

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

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

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

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

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

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

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

image.png

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

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

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

结构

image.png

同事角色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 应用按钮将成为可点击状态

image.png

一种可能的解决方法

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();
    }
}

image.png

上面的示例很简单

为了实现“点击设置字体,选择字体后预览框字体的改变以及使能应用按钮的功能”

也就是联动的功能

设置字体后,分别创建展示和按钮对象,调用对象的方法

很显然,字体不仅操心自己的事情,还管理着展示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);
    }

    @Override
    void 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();
    }
}

image.png

上面的示例中,以设置字体为例,当字体变化时,请求“项目经理”安排其他同事协助

“项目经理”operation(Colleague event) 发现是设置字体的事件后,调用对应的事件处理方法,也就是寻找其他同事进行协助

中介者模式将每个场景中对象之间的协作进行封装

小结

当你需要其他同事协助时,肯定不需要项目经理每次都创建具体的同事对象

上面的示例中,在ConcreteMediator的构造方法中创建的各个具体同事的实例(可以理解为项目经理手下有你和你的一帮同事)

你还可以提取出来工厂类用于管理同事类和中介者类

比如通过一个工厂对象管理各个同事实例(如果可以还可以将各个同事都设置为单例 )

并且中介者类作为这个工厂对象的内部类

同事对象的传递可以达到信息的获取与回调

通过给Font加了一个fontName属性,通过打印信息可以看得出来

通过将当时发生事件的对象传递了过来,可以获得事件的更多信息,可以根据信息进一步的进行操作

比如,此处的设置了字体,设置了什么字体?这一进一步的信息就通过参数携带进来

而且,这种方式还可以通知到Font本身

也就是可以在setFontEvent(Colleague event) 事件处理中,调用Font的方法进行结果返回,有回调的韵味

良好的扩展性

如果需要增加一个新的事件处理过程,比如点击取消按钮,还原字体设置,还原预览按钮

只需要在Button新增加一个职责(方法),然后在ConcreteMediator中新增加一种类型的事件处理程序即可

上面的示例中仅仅定义了几个简单的方法,实践中每个具体同事角色自然不会仅仅只有几个方法

不管有多少方法,都可以通过中介者将他们的协作逻辑进行封装

通过具体的中介者ConcreteMediator的处理方法进行安排

中介者模式可以很好地应用于事件通知的处理

中介者模式时序图

image.png

当某一个同事对象产生事件后,如果需要其他同事进行协助,他将调用中介者的方法

中介者接到消息后,调用其他同事的方法(安排其他同时干活),然后最终还可以将消息进行返回

与门面模式对比

image.png

本文作者:程序员潇然 疯狂的字节X https://crazybytex.com/

门面模式和中介者模式都是通过中间类降低系统的耦合度

但是门面模式是为了子系统提供一个简单一致的接口,客户端透过门面类向子系统发送消息,可以认为消息的发送是单方向的

客户端--->门面--->子系统方法,子系统提供功能给客户端

门面是在外部客户端和内部子系统之间

中介者模式中,则是主要复杂系统内部多个对象之间的相互协作

中介者是各个内部对象同事之间

扩展

任何模式都不是一成不变的,模式结构图只是一种相对比较合适准确的方案

但是涉及到具体的业务中,一切都是可变的

中介者模式也有多种灵活性

如果只有一个中介者对象,显然抽象Mediator角色是可以隐藏的

那么ConcreteMediator就兼顾了这个角色,提供通信接口给同事角色

中介者模式的本质含义是负责协调系统内部的多个交互的对象,将同事进行解耦

也就是说实现共同的接口并不是必须的

而实际上,一个系统中协作的多个对象,很可能是不同的类型,如果去掉了抽象角色Colleague

那么就可以将任意的有关联的对象组织在一起,通过中介者协同工作

而且,也并不意味着一定要中介者持有同事角色,如果合适,直接创建中介者也并非不可以

虽然上面提到你可以使用另外的工厂管理,那也只是一种常用用法而已。

只需要记住中介者的本质在于“行为与协作的分离,中介者封装了对象间的协作

总结

中介者模式将对象的行为和协作进行分离,使对象更加专注于对象的行为,也就是自身的功能

将协作分离出来封装到中介者内部

迪米特法则,不要和陌生人讲话,只与你的朋友通信,中介者模式是迪米特法则的典型应用

通过引入中介者对象,在同事之间的请求调用中,增加了“项目经理”,如果有事搞不定,需要协助,那么就找他

每个人只和项目经理对话,也就是仅仅和项目经理这个朋友聊天,其他的同事都不理了  ̄□ ̄||

中介者将网状结构,转换为了星型结构

将多对多的关系,转换为了一对多的关系

所以中介者模式将系统中对象对其他对象的引用数目降到最低,简化了对象之间的交互

image.png

中介者模式将各个同事对象之间进行解耦,增加新的中介者或者同事都比较方便,符合开闭原则

MVC模式,也是一种典型的中介者模式,控制器负责视图层和模型层的调度处理,是一个明显的中介者。

中介者模式将同事进行解耦,但是各个Colleague类必须同中介者进行交互

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

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

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

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

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

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

你就可以考虑中介者模式

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

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

common_log.png 转载务必注明出处:程序员潇然,疯狂的字节X,https://crazybytex.com/thread-120-1-1.html

关注下面的标签,发现更多相似文章

文章被以下专栏收录:

    黄小斜学Java

    疯狂的字节X

  • 目前专注于分享Java领域干货,公众号同步更新。原创以及收集整理,把最好的留下。
    包括但不限于JVM、计算机科学、算法、数据库、分布式、Spring全家桶、微服务、高并发、Docker容器、ELK、大数据等相关知识,一起进步,一起成长。
热门推荐
海康摄像头接入 wvp-GB28181-pro平台测试验
[md]### 简介 开箱即用的28181协议视频平台 `https://github.c
[若依]微服务springcloud版新建增添加一个
[md]若依框架是一个比较出名的后台管理系统,有多个不同版本。
[CXX1300] CMake '3.18.1' was not
[md][CXX1300] CMake '3.18.1' was not found in SDK, PATH, or