from now on，let us begin design patterns。
中介者模式
你為什麼需要中介者模式：
通用類圖:
角色解說：
抽象中介者：定義好同事類物件到中介者物件的介面，用於各個同事類之間的通訊。一般包括乙個或幾個抽象的事件方法，並由子類去實現。
中介者實現類：從抽象中介者繼承而來，實現抽象中介者中定義的事件方法。從乙個同事類接收訊息，然後通過訊息影響其他同時類。
同事類：如果乙個物件會影響其他的物件，同時也會被其他物件影響，那麼這兩個物件稱為同事類。在類圖中，同事類只有乙個，這其實是現實的省略，在實際應用中，同事類一般由多個組成，他們之間相互影響，相互依賴。同事類越多，關係越複雜。並且，同事類也可以表現為繼承了同乙個抽象類的一組實現組成。在中介者模式中，同事類之間必須通過中介者才能進行訊息傳遞。
由於中介者模式在定義上比較鬆散，在結構上和觀察者模式、命令模式十分相像；而應用目的又與結構模式「門面模式」有些相似。
從目的上看，中介者模式與觀察者模式、命令模式便沒有了任何關係，倒是與前面講過的門面模式有些相似。
但是門面模式是介於客戶程式與子系統之間的，而中介者模式是介於子系統與子系統之間的。這也注定了它們有很大的區別：門面模式是將原有的複雜邏輯提取到乙個統一的介面，簡化客戶對邏輯的使用。它是被客戶所感知的，而原有的複雜邏輯則被隱藏了起來。而中介者模式的加入並沒有改變客戶原有的使用習慣，它是隱藏在原有邏輯後面的，使得**邏輯更加清晰可用。
前面已經陸陸續續的將中介者模式的特點寫了出來。這裡再總結一下。使用中介者模式最大的好處就是將同事角色解耦。這帶來了一系列的系統結構改善：提高了原有系統的可讀性、簡化原有系統的通訊協議——將原有的多對多變為一對多、提高了**的可復用性……
呵呵，但是中介者角色集中了太多的責任，所有有關的同事物件都要由它來控制。這不由得讓我想起了簡單工廠模式，但是由於中介者模式的特殊性——與業務邏輯密切相關，不能採用類似工廠方法模式的解決方法。
濫用中介者模式，只會讓事情變的更複雜
我們熟悉的mvc模式，其中的controller就是中介者模式很好的實現。
因此建議在使用中介者模式的時候注意控制中介者角色的大小。
先看乙個反例：
這裡的a和b是直接耦合在一起的，以後我們要改a的時候會牽涉到所有與a關聯的類，耦合度太高。
中介者模式的例子：
同事類：
抽象中介者類：
介者類：
客戶端：
雖然**比較長，但是還是比較容易理解的，其實就是把原來處理物件關係的**重新封裝到乙個中介類中，通過這個中介類來處理物件間的關係。
C 設計模式 16 中介者模式
中介者模式，定義了乙個中介物件來封裝一系列物件之間的互動關係，中介者使各個物件之間不需要顯式地相互引用，從而降低耦合性。在開發中我們會遇到各個物件相互引用的情況，每個物件都可以和多個物件進行互動，這時將會形成複雜的一對多結構的網狀結構，各個物件之間過度耦合，這樣不利於類的復用和擴充套件。如果引入了中...
設計模式 21 中介者模式
中介者模式 用乙個中介物件來封裝一系列的物件互動 中介者 就像我們在租房子一樣，有租房子的中介 抽象中介者 mediator package com.actionpattern.intermediary.edition1 抽象中介者 mediator public abstract class me...
設計模式17 中介者模式
中介者模式 mediator pattern 是用來降低多個物件和類之間的通訊複雜性。這種模式提供了乙個中介類，該類通常處理不同類之間的通訊，並支援松耦合，使 易於維護。中介者模式屬於行為型模式。不應當在職責混亂的時候使用。建立中介類 聊天室，負責傳送通訊 include include inclu...