場景：多部門相互依賴，協同工做
相信你們都去超市買過東西，很是方便，並且超市貨架上的貨源不會斷貨，爲了保證這一點，超市必定有本身的一個倉庫，以便隨時補貨。既然有了倉庫，就要有專門的人員從外面採購物品來存到倉庫，針對這個場景，咱們抽取出三個角色部門：銷售部門、倉庫部門、採購部門。這三個部門之間是相互依賴的。採購部門要根據銷售部門的銷售狀況肯定是否採購，也須要根據倉庫的庫存量決定是否採購，而銷售部門只有在倉庫部門有庫存的狀況下才能正常銷售。咱們大體畫個圖來表示三者之間的關係：微信
根據上面的分析，咱們能夠設計出以下類圖：架構
代碼清單以下。採購部門：app
倉庫部門：學習
銷售部門：編碼
場景類：spa
運行結果爲：.net
程序功能達到了咱們的指望，也能正常進行運轉，無論怎麼說，任務算是完成了。設計
存在的缺陷
咱們從新看一下咱們的程序，每一個類都與其餘兩個類產生了關聯，根據迪米特法則，每一個類只和朋友類交流，這個朋友類，並非越多越好，朋友類越多，耦合性越大，想要修改一個類就得修改一大片，這不是面向對象設計所指望的，何況這裏仍是隻有三個部門的狀況，現實中，一個公司可能會有幾十個部門，而且各個部門之間也都是存在關聯的，造成了一個蜘蛛網的結構，若是按照上面方式進行編碼的話，單單維護起來就已經讓人頭大了。因此，咱們必須對上面的代碼進行從新設計。3d
針對這個問題，咱們能夠引入一箇中介者，各個部門只與這個中介者對象進行交互，與本身無關的活動都丟給這個中介者去處理，這就是所謂的中介者模式。orm
中介者模式
中介者模式：用一箇中介對象封裝一系列的對象交互，中介者使各對象不須要顯示地相互做用，從而使其鬆耦合，並且能夠獨立地改變他們之間的交互。
中介者模式由如下幾個部分組成：
1. Mediator抽象中介者角色
抽象中介者角色定義統一的接口，用於各同事角色之間的通訊。
2. Concrete Mediator具體中介者角色
具體中介者角色經過協調各同事角色實現協做行爲，所以，他必須依賴於各個同事角色。
3. Colleague同事角色
每個同事角色都知道中介者角色，並且與其餘的同事角色通訊的時候，必定要經過中介者角色協做。每一個同事類的行爲分爲兩種：一種是同事自己的行爲，好比改變對象自己的狀態，處理本身的行爲等，這種行爲叫作自發行爲，與其餘的同事類或者中介者沒有任何的依賴；第二種是必須依賴中介者才能完成的行爲，叫作依賴方法。
它們之間的關係以下圖：
代碼清單以下，抽象同事類：
它只持有一個抽象中介者的對象，交給子類去調用。
具體同事類：
抽象中介者：
它持有各個同事類的對象，而且在本身的業務邏輯處理中調用這些同事類對象的方法。
具體的中介者：
中介者所具備的方法都是比較複雜的業務邏輯，爲同事類服務，其實現是依賴各個同事類來完成的。
使用中介者模式改造例子代碼
學習了中介者模式後，咱們如今來對上面例子中的代碼進行改造。首先設計以下類圖：
創建了兩個抽象類AbstractMediator和AbstractColleague，每一個對象只是與中介者Mediator之間產生依賴，與其餘對象之間沒有直接關係。代碼清單以下：
抽象中介者：
具體的中介者，咱們能夠根據業務的要求產生出多箇中介者，並劃分各中介者的職責：
抽象同事類：
修改後的採購部門：
修改後的倉庫部門：
修改後的銷售部門：
修改後的場景類：
最後運行程序，結果是相同的。
中介者模式的應用
中介者模式的優勢就是減小了類間的依賴，把原有的一對多的依賴變成了一對一的依賴，下降了類間的耦合。
中介者模式的缺點就是中介者會膨脹的很大，並且邏輯複雜，同事類越多，中介者的邏輯就越複雜。
中介者模式適用於多個對象之間緊密耦合的狀況，緊密耦合的標準是：在類圖中出現了蜘蛛網狀結構。
點個關注吧，進入個人主頁獲取更多幹貨~
本文分享自微信公衆號 - Java架構成長之路（K469785635）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。