偶然間看到了一個之前完全沒有關注過的設計模式——中介者模式，在看過該設計模式的應用場景後，便有了相見恨晚的感覺啊！！！
這麼屌的設計模式應該應用很廣泛呀！！可怎麼之前都沒怎麼聽過?難道是我之前以爲『中介者模式』==『代理模式』嗎？???不過話說回來，只看名字的話，很多人都會以爲這兩個是同一種設計模式吧……
廢話不多說，我們接下來介紹下這個非常屌的設計模式。這裏是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