设计模式之中介者模式

在我们实际业务中,可能存在多个类之间相互调用,形成了一个复杂的网状结构。这时候就需要有一种模式去“捋顺”他们之间的关系,引出一个中间者让类之间不再相互调用,该模式就是我们今天的主人公——中介者模式。

一、概念理解

我们先看中介者模式的官方概念:用一个中介者对象来封装一系列的对象交互,中介者使各对象不需要显示地相互引用,从而使其松散耦合,而且可以独立地改变它们之间的交互。

大白话解释就是,引入一个“中介”,用于协调各个对象的关系,各个对象之间不用那么直白的直接调,对象只需要调用中介的方法,中介内部进行逻辑判断,由中介去调用各个对象的方法。

概念基本清楚以后接着看中介者模式包含的角色都有哪些:

中介者角色、各个对象角色是必须的,在面向接口编程原则下,中介者和对象应该抽离出来接口,于是在中介者模式的结构中就包括四种角色(各个对象角色称为同事):

1.中介者(Mediator):中介者是一个接口,该接口定义了用于同事(Colleague)对象之间进行通信的方法;

2.具体中介者(ConcreteMediator):具体中介者是实现中介者接口的类。具体中介者需要包含所有具体同事(ConcreteColleague)的引用,并通过实现中介者接口中的方法来满足具体同事之间的通信要求;

3.同事(Colleague):一个接口,规定了具体同事需要实现的方法;

4.具体同事(ConcreteColleague):实现了同事接口的类。具体同事需要包含具体中介者的引用,一个具体同事需要和其他具体同事交互时,只需将自己的请求通知给它所包含的具体中介者的引用。

如果在一个业务场景中,一个公司有很多同事,同事1 管理的有自己的数据,有时候也会调用同事2的数据。

在中介者模式下,同事1和同事2 之间不再相互调用,由中介者统一调用,同事类中要持有中介者对象,中介者方法中要有判断属于哪个角色的方法。

基于四个角色,实现初试的demo。

读者可以拉取完整代码到本地进行学习,实现代码均测试通过后上传到码云

二、案例实现

抽象同事类:

抽象同事中要持有中介者的引用

/**
 * 抽象同事类
 * @author tcy
 * @Date 14-09-2022
 */
public abstract class Colleague {

    //抽象中介者引用
    protected Mediator mediator;

    public Colleague(Mediator mediator)
    {
        this.mediator = mediator;
    }
    //数据更新方法
    public abstract void update();
    //数据更改方法
    public abstract void changed();
}

具体同事类1、2:

具体同事类除了有自己的业务逻辑之外,应该还有额外调用中介者的方法

/**
 * 具体同事2
 * @author tcy
 * @Date 14-09-2022
 */

public class ConcreteColleague2 extends Colleague {

    public ConcreteColleague2(Mediator mediator)
    {
        super(mediator);
    }

    //自己的方法
    @Override
    public void update()
    {
        System.out.println("更新同事类2");
    }

    //调用同事的方法
    @Override
    public void changed()
    {
        System.out.println("同事类2数据更改");
        mediator.operation(this);
    }

}

/**
 * 具体同事1
 * @author tcy
 * @Date 14-09-2022
 */
public class ConcreteColleague1 extends Colleague{

    public ConcreteColleague1(Mediator mediator)
    {
        super(mediator);
    }

    @Override
    public void update()
    {
        System.out.println("更新同事类1");
    }

    @Override
    public void changed()
    {
        System.out.println("同事类1数据更改");
        mediator.operation(this);
    }

}

抽象中介者:

抽象中介者应该是持有所有同事对象,并且应该有一个方法去调用别的同事

/**
 * 抽象中介者
 */
public abstract class Mediator {

    protected ArrayList colleagues = new ArrayList();

    public void add(Colleague colleague)
    {
        colleagues.add(colleague);
    }

    public abstract void operation(Colleague colleague);

}

具体中介者:

具体中介者实现抽象中介者的方法,根据条件调用不同的同事

/**
 * 具体中介者
 * @author tcy
 * @Date 14-09-2022
 */
public class ConcreteMediator extends Mediator {

    @Override
    public void operation(Colleague colleague)
    {
        if(colleague instanceof ConcreteColleague1)
            colleagues.get(1).update();
        else if(colleague instanceof ConcreteColleague2)
            colleagues.get(0).update();
    }

}

三、中介者模式源码中的应用

中介者模式的典型应用就是Jdk中的Timer 类。

我们知道Timer 类的主要作用是用于定时任务,定时任务之间会存在通信问题,如果众多的定时任务都相互通信,那对于系统对象间的引用来说就是一灾难,引出中介者模式就是理所应当的了。

当有新的任务加入到队列中,均把该任务当做同事,各个任务之间的通信都是由Timer 类来完成,Timer 类就相当于中介者的角色。

我们知道,Timer 类实现定时任务的主要方法就是schedule(),schedule()有一堆的重载方法。

设计模式之中介者模式插图1

我们点开任意的schedule方法。

public void schedule(TimerTask task, Date firstTime, long period) {
    if (period 

均调用了sched()私有方法。

设计模式之中介者模式插图2

我们重点看红线标记的代码块,将任务放入一个 队列中,这个队列和我们例子中的Arrlist是一个作用。

private final TaskQueue queue = new TaskQueue();

判断以后,调用Object的notify()方法,进行线程间的通信。

试想一下,如果没有这个中介,每个定时任务都手动的调用notify()方法,该有多么痛苦。

四、总结

网上讲解设计模式的文章很多,能把中介模式讲清楚很简单,但能说明白何时使用合适的设计模式却是难上加难。在前三章设计模式的基础之上,第四章总结看完,希望读者能对正确使用设计模式有一个清晰的轮廓。

很多网上的博客都说要职责清晰才可使用中介者模式,如果类的职责是混乱的,那中介者的逻辑写起来就很难受。还有多个对象间耦合严重,类图之间出现了网状结构,这时候就可以考虑中介者模式了,如果仅仅是为了使用中介者模式而使用,那就得不偿失了。

中介者的优点突出,中介者模式的出现会让网状结构,有序的转化为星状结构。能有序降低类的复杂度,将多对多的关系转化为一对多,降低了类之间的耦合。

缺点也很明显,会增加类的个数,同事类越多,中介者的逻辑也就越复杂。

我已经连续更新了十几篇设计模式博客,推荐你一块学习。

一、设计模式概述

二、设计模式之工厂方法和抽象工厂

三、设计模式之单例和原型

四、设计模式之建造者模式

五、设计模式之代理模式

六、设计模式之适配器模式

七、设计模式之桥接模式

八、设计模式之组合模式

九、设计模式之装饰器模式

十、设计模式之外观模式

十一、外观模式之享元模式

十二、设计模式之责任链模式

十三、设计模式之命令模式

十四、设计模式之解释器模式

十五、设计模式之迭代器模式

文章来源于互联网:设计模式之中介者模式

THE END
分享
二维码