偶然间看到了一个之前完全没有关注过的设计模式——中介者模式,在看过该设计模式的应用场景后,便有了相见恨晚的感觉啊!!!
这么屌的设计模式应该应用很广泛呀!!可怎么之前都没怎么听过?难道是我之前以为『中介者模式』==『代理模式』吗????不过话说回来,只看名字的话,很多人都会以为这两个是同一种设计模式吧……
废话不多说,我们接下来介绍下这个非常屌的设计模式。这里是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