偶然间看到了一个之前完全没有关注过的设计模式——中介者模式，在看过该设计模式的应用场景后，便有了相见恨晚的感觉啊！！！
这么屌的设计模式应该应用很广泛呀！！可怎么之前都没怎么听过?难道是我之前以为『中介者模式』==『代理模式』吗？???不过话说回来，只看名字的话，很多人都会以为这两个是同一种设计模式吧……
废话不多说，我们接下来介绍下这个非常屌的设计模式。这里是demo（传送门）。
一、应用场景
『中介者模式』的设计初衷就是为了各个互相关联的模块之间的解耦。如果在业务场景中，几个模块会相互影响，那你会怎么设计程序呢？
在知道中介者模式之前，我能想到的就是回调……举个栗子，在之前做日历页开发时，日历页主要被分为五个模块：
- PriceCalendarDelegate（日历模块）
- MultilineDelegate（多项目模块）
- MultiTravelDelegate（多行程模块）
- NumberBoxDelegate（人数选择模块）
- FooterDelegate（底部模块）
这五个模块可以说是非常紧密地关联在一起。下面是全部模块的展示图。
当我们选中一个日期，比如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到了『中介者模式』有多屌了，就跟我来具体了解下这个设计模式吧~~~
三、中介者模式详解
1. 定义
中介者模式包装了一系列对象相互作用的方式，使得这些对象不必相互明显作用。从而使它们可以松散耦合。当某些对象之间的作用发生改变时，不会立即影响其他的一些对象之间的作用。保证这些作用可以彼此独立的变化。
2. 使用场景：
当对象之间的交互操作很多且每个对象的行为操作都依赖彼此时，为防止在修改一个对象的行为时，同时涉及很多其他对象的行为，可使用中介者模式。
3. UML类图
这是我在网上找的一张类图。。。。由于现在已经快12点了，之后有时间再自己画一张吧。。。
四、总结
八个字概括：
模块解耦！！中介者模式！！
五、参考
https://www.cnblogs.com/ysw-go/p/5413958.html
https://blog.csdn.net/u012124438/article/details/70474166
https://blog.csdn.net/ztg1234/article/details/78359253