在我們實(shí)際業(yè)務(wù)中，可能存在多個類之間相互調(diào)用，形成了一個復(fù)雜的網(wǎng)狀結(jié)構(gòu)。這時候就需要有一種模式去“捋順”他們之間的關(guān)系，引出一個中間者讓類之間不再相互調(diào)用，該模式就是我們今天的主人公——中介者模式。

一、概念理解

我們先看中介者模式的官方概念：用一個中介者對象來封裝一系列的對象交互，中介者使各對象不需要顯示地相互引用，從而使其松散耦合，而且可以獨(dú)立地改變它們之間的交互。

大白話解釋就是，引入一個“中介”，用于協(xié)調(diào)各個對象的關(guān)系，各個對象之間不用那么直白的直接調(diào)，對象只需要調(diào)用中介的方法，中介內(nèi)部進(jìn)行邏輯判斷，由中介去調(diào)用各個對象的方法。

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

中介者角色、各個對象角色是必須的，在面向接口編程原則下，中介者和對象應(yīng)該抽離出來接口，于是在中介者模式的結(jié)構(gòu)中就包括四種角色（各個對象角色稱為同事）：

1.中介者（Mediator）：中介者是一個接口，該接口定義了用于同事（Colleague）對象之間進(jìn)行通信的方法；

2.具體中介者（ConcreteMediator）：具體中介者是實(shí)現(xiàn)中介者接口的類。具體中介者需要包含所有具體同事（ConcreteColleague）的引用，并通過實(shí)現(xiàn)中介者接口中的方法來滿足具體同事之間的通信要求；

3.同事（Colleague）：一個接口，規(guī)定了具體同事需要實(shí)現(xiàn)的方法；

4.具體同事（ConcreteColleague）：實(shí)現(xiàn)了同事接口的類。具體同事需要包含具體中介者的引用，一個具體同事需要和其他具體同事交互時，只需將自己的請求通知給它所包含的具體中介者的引用。

如果在一個業(yè)務(wù)場景中，一個公司有很多同事，同事1 管理的有自己的數(shù)據(jù)，有時候也會調(diào)用同事2的數(shù)據(jù)。

在中介者模式下，同事1和同事2 之間不再相互調(diào)用，由中介者統(tǒng)一調(diào)用，同事類中要持有中介者對象，中介者方法中要有判斷屬于哪個角色的方法。

基于四個角色，實(shí)現(xiàn)初試的demo。

讀者可以拉取完整代碼到本地進(jìn)行學(xué)習(xí)，實(shí)現(xiàn)代碼均測試通過后上傳到碼云。

本地源碼下載

二、案例實(shí)現(xiàn)

抽象同事類：

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

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

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

    public Colleague(Mediator mediator)
    {
        this.mediator = mediator;
    }
    //數(shù)據(jù)更新方法
    public abstract void update();
    //數(shù)據(jù)更改方法
    public abstract void changed();
}

具體同事類1、2：

具體同事類除了有自己的業(yè)務(wù)邏輯之外，應(yīng)該還有額外調(diào)用中介者的方法

/**
 * 具體同事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");
    }

    //調(diào)用同事的方法
    @Override
    public void changed()
    {
        System.out.println("同事類2數(shù)據(jù)更改");
        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數(shù)據(jù)更改");
        mediator.operation(this);
    }


}

抽象中介者：

抽象中介者應(yīng)該是持有所有同事對象，并且應(yīng)該有一個方法去調(diào)用別的同事

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

    protected ArrayList<Colleague> colleagues = new ArrayList<>();

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

    public abstract void operation(Colleague colleague);

}

具體中介者：

具體中介者實(shí)現(xiàn)抽象中介者的方法，根據(jù)條件調(diào)用不同的同事

/**
 * 具體中介者
 * @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();
    }

}

三、中介者模式源碼中的應(yīng)用

中介者模式的典型應(yīng)用就是Jdk中的Timer 類。

我們知道Timer 類的主要作用是用于定時任務(wù)，定時任務(wù)之間會存在通信問題，如果眾多的定時任務(wù)都相互通信，那對于系統(tǒng)對象間的引用來說就是一災(zāi)難，引出中介者模式就是理所應(yīng)當(dāng)?shù)牧恕?/p>

當(dāng)有新的任務(wù)加入到隊(duì)列中，均把該任務(wù)當(dāng)做同事，各個任務(wù)之間的通信都是由Timer 類來完成，Timer 類就相當(dāng)于中介者的角色。

我們知道，Timer 類實(shí)現(xiàn)定時任務(wù)的主要方法就是schedule(),schedule()有一堆的重載方法。

我們點(diǎn)開任意的schedule方法。

public void schedule(TimerTask task, Date firstTime, long period) {
    if (period <= 0)
        throw new IllegalArgumentException("Non-positive period.");
    sched(task, firstTime.getTime(), -period);
}

均調(diào)用了sched()私有方法。

我們重點(diǎn)看紅線標(biāo)記的代碼塊，將任務(wù)放入一個 隊(duì)列中，這個隊(duì)列和我們例子中的Arrlist是一個作用。

private final TaskQueue queue = new TaskQueue();

判斷以后，調(diào)用Object的notify()方法，進(jìn)行線程間的通信。

試想一下，如果沒有這個中介，每個定時任務(wù)都手動的調(diào)用notify()方法，該有多么痛苦。

四、總結(jié)

網(wǎng)上講解設(shè)計(jì)模式的文章很多，能把中介模式講清楚很簡單，但能說明白何時使用合適的設(shè)計(jì)模式卻是難上加難。在前三章設(shè)計(jì)模式的基礎(chǔ)之上，第四章總結(jié)看完，希望讀者能對正確使用設(shè)計(jì)模式有一個清晰的輪廓。

很多網(wǎng)上的博客都說要職責(zé)清晰才可使用中介者模式，如果類的職責(zé)是混亂的，那中介者的邏輯寫起來就很難受。還有多個對象間耦合嚴(yán)重，類圖之間出現(xiàn)了網(wǎng)狀結(jié)構(gòu)，這時候就可以考慮中介者模式了，如果僅僅是為了使用中介者模式而使用，那就得不償失了。

中介者的優(yōu)點(diǎn)突出，中介者模式的出現(xiàn)會讓網(wǎng)狀結(jié)構(gòu)，有序的轉(zhuǎn)化為星狀結(jié)構(gòu)。能有序降低類的復(fù)雜度，將多對多的關(guān)系轉(zhuǎn)化為一對多，降低了類之間的耦合。

缺點(diǎn)也很明顯，會增加類的個數(shù)，同事類越多，中介者的邏輯也就越復(fù)雜。

以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，謝謝大家對腳本之家的支持。如果你想了解更多相關(guān)內(nèi)容請查看下面相關(guān)鏈接

最新評論