【设计模式】中介者模式：设计模式中的解耦神器！！（附上demo）

偶然间看到了一个之前完全没有关注过的设计模式——中介者模式，在看过该设计模式的应用场景后，便有了相见恨晚的感觉啊！！！

这么屌的设计模式应该应用很广泛呀！！可怎么之前都没怎么听过?难道是我之前以为『中介者模式』==『代理模式』吗？???不过话说回来，只看名字的话，很多人都会以为这两个是同一种设计模式吧……

废话不多说，我们接下来介绍下这个非常屌的设计模式。这里是demo（传送门）。

一、应用场景

『中介者模式』的设计初衷就是为了各个互相关联的模块之间的解耦。如果在业务场景中，几个模块会相互影响，那你会怎么设计程序呢？

在知道中介者模式之前，我能想到的就是回调……举个栗子，在之前做日历页开发时，日历页主要被分为五个模块：

PriceCalendarDelegate（日历模块）
MultilineDelegate（多项目模块）
MultiTravelDelegate（多行程模块）
NumberBoxDelegate（人数选择模块）
FooterDelegate（底部模块）

这五个模块可以说是非常紧密地关联在一起。下面是全部模块的展示图。
日历页模块效果图.jpg
当我们选中一个日期，比如4月18号时，多线路模块、多行程模块、人数选择模块都需要跟着改变。
那么我的程序是怎么写的呢？

override fun onDateSelected(dayStrObj: String, priceStr: Int?, productPrices: List<ProductPrice>?) {
        //底部模块刷新
        PriceCalendarUtil.setSuccessFetchPrice(true, mPresenter)
        mFooterDelegate?.refresh(true)
        //多线路模块刷新
        if (PriceCalendarUtil.isTour(mPresenter) && PriceCalendarUtil.isMultiLine(mPresenter)) {
            mMultiTravelDelegate?.refresh(dayStrObj, null)
            mMultiLineDelegate?.refresh(dayStrObj, productPrices)
            return
        }
        //多行程模块刷新
        if (PriceCalendarUtil.isTour(mPresenter)) {
            mMultiTravelDelegate?.refresh(dayStrObj, productPrices)
        }
        //优惠券模块刷新
        requestPriceAndCoupon(dayStrObj, priceStr)
    }

这个是选择完日期后的回调，在这个回调里，多行程模块、优惠券模块、底部模块、多线路模块都需要重新刷新。

这只是Fragment中的一个回调，由于日历页的各个模块都需要关联起来，这样的回调还有好多。红框框出来的都是回调。
这里写图片描述

二、有了中介者模式之后，我们的代码该怎么写呢？

由于日历页的代码量很大，不适合理解中介者模式的精髓，我们来写个demo。
在demo里有三个Delegate：

DelegateA
DelegateB
DelegateC
BaseDelegate

这三个Delegate就相当于三个模块，另外BaseDelegate是它们的父类。
除了这三个Delegate，还有一个中介者Mediator。

接下来只需要在Activity里初始化一下三个Delegate和一个Mediator就行了。

我们看到，在Activity里再也没有了那么多冗余的回调，我们可以直接在各个业务模块里去更改其他模块了！

这样的代码层次更清晰，也更有可读性！！

好了，读到这里如果你已经get到了『中介者模式』有多屌了，就跟我来具体了解下这个设计模式吧~~~