中介者模式 Mediator
意圖
用一箇中介對象來封裝一系列的對象交互。中介者使各對象不需要顯式的相互引用，從而使其耦合鬆散，而且可以獨立的改變他們之間的交互。
場景
假設一個包含按鈕、菜單和輸入域的彈出，通常彈出框中各個組件之間存在依賴關係，比如，當輸入域爲空時某個按鈕不能使用；在輸入域中屬於內容會自動選擇並展示一個或多個列表條目；一旦正文出現在輸入域中，其他一些按鈕可能就變得能夠使用了，而這些按鈕允許用戶做一些操作，比如改變或刪除正文內容等。
- 從事圖形界面類軟件(Android、PC、Mac、iOS等操作系統應用軟件)開發的人似乎從來不需要擔心這個問題，因爲雖然我們面臨着大量的類似場景，但是我們似乎從來沒有爲這種場景犯愁過。其實在圖形界面的開發工作中我們不可避免的會用到該模式，也正因爲此，我們才從不需要爲這種場景去發愁。拿Android來說，在Activity中將會有所有需要用到的View的引用，所有的事件將會通過Activity進行中轉。在這種場景下，一般用於圖形界面開發的SDK都直接提供中介者用於具體操作。
- 或許你會問，除了這樣還有其他方式嗎？有，但是毫無疑問這種方式更爲直觀方便，易於修改。
拓展
雖然有中介者模式的天生支持，但是這樣我們就高枕無憂了嗎？並不是，有更多的工作需要我們開發者去做。
繼續以Android爲例，在Android開發中，雖然可以通過Activity作爲中介者實現中介者模式對View複雜的依賴關係進行處理，但是需要注意的是，在Activity中還有其複雜的生命週期需要處理，在其生命週期中往往有更重要的信息需要去處理，比如用戶數據等。很明顯同時再承擔各個View之間的中介將極大的加重Activity的任務量，這將造成兩點主要壞處：
- 中介者作爲一個連接各個類之間關係的橋樑，應該可以沒有限制的去重構、或者重寫一個，但是Activity因爲包含了生命週期的相關處理，重構時需要小心是否影響到了生命週期中的處理內容，重寫的時候需要再將生命週期處理函數重新寫一遍。總結起來就是麻煩。
- View之間和Activity生命週期之間很容易產生硬性的直接的連接調用，當這個View不再存在時還需要單獨去處理Activity代碼，像上面說的一樣，很容易傷及無辜。
很明顯我們需要自己添加一種處理手段避免該現象的產生。
MVP模式雖然主要目的不僅僅是爲了解決這麼小的一個問題，但是他卻很好的通過他的View層解決了該問題。MVP中的IViewBase接口定義了各狀態下的顯式效果，而作爲開發者的我們可以通過不斷的實現MVP中IViewBase層接口去不斷地產生具有不同效果的中介者。但需要注意的是，如果通過Activity直接繼承IViewBase應該減少Activity中各回調函數對View的直接調用，可以間接的去掉用MVP中的IViewBase中的方法或者其他層的接口方法間接實現需求。