1、引言html
在現實生活中,有不少中介者模式的身影,例如QQ遊戲平臺,聊天室、QQ羣和短信平臺,這些都是中介者模式在現實生活中的應用,下面就具體分享下我對中介者模式的理解。編程
2、 中介者模式的介紹ide
2.1 中介者模式的定義this
從生活中的例子能夠看出,不管是QQ遊戲仍是QQ羣,它們都是充當一箇中間平臺。QQ用戶能夠登陸這個中間平臺與其餘QQ用戶進行交流,若是沒有這些中間平臺,咱們若是想與朋友進行聊天的話,可能就須要當面才能夠了。電話、短信也一樣是一箇中間平臺,有了這個中間平臺,每一個用戶都不須要直接依賴與其餘用戶,只須要依賴這個中間平臺就能夠了,一切操做都由中間平臺去分發。瞭解完中介模式在生活中的模型後,下面給出中介模式的正式定義。spa
中介者模式,定義了一箇中介對象來封裝一系列對象之間的交互關係。中介者使各個對象之間不須要顯式地相互引用,從而使耦合性下降,並且能夠獨立地改變它們之間的交互行爲。設計
2.2 中介者模式的結構3d
從生活中例子天然知道,中介者模式設計兩個具體對象:一個是用戶類,另外一個是中介者類。根據針對接口編程原則,則須要把這兩類角色進行抽象,因此中介者模式中就有了4類角色,它們分別是:抽象中介者角色,具體中介者角色、抽象同事類和具體同事類。中介者類是起到協調各個對象的做用,則抽象中介者角色中則須要保存各個對象的引用。有了上面的分析,則就不難理解中介者模式的結構圖了,具體結構圖以下所示:code
爲何要使用中介者模式
htm
在現實生活中,中介者的存在是不可缺乏的,若是沒有了中介者,咱們就不能與遠方的朋友進行交流了。而在軟件設計領域,爲何要使用中介者模式呢?若是不使用中介者模式的話,各個同事對象將會相互進行引用,若是每一個對象都與多個對象進行交互時,將會造成以下圖所示的網狀結構。對象
從上圖能夠發現,若是不使用中介者模式的話,每一個對象之間過分耦合,這樣既不利於類的複用也不利於擴展。若是引入了中介者模式,那麼對象之間的關係將變成星型結構,採用中介者模式以後會造成以下圖所示的結構:
從上圖能夠發現,使用中介者模式以後,任何一個類的變化,只會影響中介者和類自己,不像以前的設計,任何一個類的變化都會引發其關聯全部類的變化。這樣的設計大大減小了系統的耦合度。
2.3 中介者模式的實現
介紹完中介者模式的定義和存在的必要性後,下面就以現實生活中打牌的例子來實現下中介者模式。在現實生活中,兩我的打牌,若是某我的贏了都會影響到對方狀態的改變。若是此時不採用中介者模式實現的話,則上面的場景的實現以下所示:
// 抽象牌友類 public abstract class AbstractCardPartner { public int MoneyCount { get; set; } public AbstractCardPartner() { MoneyCount = 0; } public abstract void ChangeCount(int Count, AbstractCardPartner other); } // 牌友A類 public class ParterA : AbstractCardPartner { public override void ChangeCount(int Count, AbstractCardPartner other) { this.MoneyCount += Count; other.MoneyCount -= Count; } } // 牌友B類 public class ParterB : AbstractCardPartner { public override void ChangeCount(int Count, AbstractCardPartner other) { this.MoneyCount += Count; other.MoneyCount -= Count; } } class Program { // A,B兩我的打牌 static void Main(string[] args) { AbstractCardPartner A = new ParterA(); A.MoneyCount = 20; AbstractCardPartner B = new ParterB(); B.MoneyCount = 20; // A 贏了則B的錢就減小 A.ChangeCount(5, B); Console.WriteLine("A 如今的錢是:{0}", A.MoneyCount);// 應該是25 Console.WriteLine("B 如今的錢是:{0}", B.MoneyCount); // 應該是15 // B贏了A的錢也減小 B.ChangeCount(10, A); Console.WriteLine("A 如今的錢是:{0}", A.MoneyCount); // 應該是15 Console.WriteLine("B 如今的錢是:{0}", B.MoneyCount); // 應該是25 Console.Read(); } }
上面確實完美解決了上面場景中的問題,而且使用了抽象類使具體牌友A和牌友B都依賴於抽象類,從而下降了同事類之間的耦合度。可是這樣的設計,若是其中牌友A發生變化時,此時就會影響到牌友B的狀態。若是涉及的對象變多的話,這時候某一個牌友的變化將會影響到其餘全部相關聯的牌友狀態。例如牌友A算錯了錢,這時候牌友A和牌友B的錢數都不正確了。若是是多我的打牌的話,影響的對象就會更多。這時候就會思考——能不能把算錢的任務交給程序或者算數好的人去計算呢,這時候就有了咱們QQ遊戲中的歡樂鬥地主等牌類遊戲了。因此上面的設計,咱們仍是有進一步完善的方案的,即加入一箇中介者對象來協調各個對象之間的關聯,這也就是中介者模式的應用了,具體完善後的實現代碼以下所示:
namespace MediatorPattern { // 抽象牌友類 public abstract class AbstractCardPartner { public int MoneyCount { get; set; } public AbstractCardPartner() { MoneyCount = 0; } public abstract void ChangeCount(int Count, AbstractMediator mediator); } // 牌友A類 public class ParterA : AbstractCardPartner { // 依賴與抽象中介者對象 public override void ChangeCount(int Count, AbstractMediator mediator) { mediator.AWin(Count); } } // 牌友B類 public class ParterB : AbstractCardPartner { // 依賴與抽象中介者對象 public override void ChangeCount(int Count, AbstractMediator mediator) { mediator.BWin(Count); } } // 抽象中介者類 public abstract class AbstractMediator { protected AbstractCardPartner A; protected AbstractCardPartner B; public AbstractMediator(AbstractCardPartner a, AbstractCardPartner b) { A = a; B = b; } public abstract void AWin(int count); public abstract void BWin(int count); } // 具體中介者類 public class MediatorPater : AbstractMediator { public MediatorPater(AbstractCardPartner a, AbstractCardPartner b) : base(a, b) { } public override void AWin(int count) { A.MoneyCount += count; B.MoneyCount -= count; } public override void BWin(int count) { B.MoneyCount += count; A.MoneyCount -= count; } } class Program { static void Main(string[] args) { AbstractCardPartner A = new ParterA(); AbstractCardPartner B = new ParterB(); // 初始錢 A.MoneyCount = 20; B.MoneyCount = 20; AbstractMediator mediator = new MediatorPater(A, B); // A贏了 A.ChangeCount(5, mediator); Console.WriteLine("A 如今的錢是:{0}", A.MoneyCount);// 應該是25 Console.WriteLine("B 如今的錢是:{0}", B.MoneyCount); // 應該是15 // B 贏了 B.ChangeCount(10, mediator); Console.WriteLine("A 如今的錢是:{0}", A.MoneyCount);// 應該是15 Console.WriteLine("B 如今的錢是:{0}", B.MoneyCount); // 應該是25 Console.Read(); } } }
從上面實現代碼能夠看出,此時牌友A和牌友B都依賴於抽象的中介者類,這樣若是其中某個牌友類變化只會影響到,只會影響到該變化牌友類自己和中介者類,從而解決前面實現代碼出現的問題。具體的運行結果和前面實現結果同樣,運行結果以下圖所示:
在上面的實現代碼中,抽象中介者類保存了兩個抽象牌友類,若是新添加一個牌友相似時,此時就不得不去更改這個抽象中介者類。能夠結合觀察者模式來解決這個問題,即抽象中介者對象保存抽象牌友的類別,而後添加Register和UnRegister方法來對該列表進行管理。而後在具體中介者類中修改AWin和BWin方法,遍歷列表,改變本身和其餘牌友的錢數。這樣的設計仍是存在一個問題——即增長一個新牌友時,此時雖然解決了抽象中介者類不須要修改的問題,但此時仍是不得不去修改具體中介者類,即添加CWin方法。咱們能夠採用狀態模式來解決這個問題。
3、中介者模式的適用場景
通常在如下狀況下能夠考慮使用中介者模式:
1)一組定義良好的對象,如今要進行復雜的相互通訊。
2)想經過一箇中間類來封裝多個類中的行爲,而又不想生成太多的子類。
4、中介者模式的優缺點
中介者模式具備如下幾點優勢:
1)簡化了對象之間的關係,將系統的各個對象之間的相互關係進行封裝,將各個同事類解耦,使得系統變爲鬆耦合。
2)提供系統的靈活性,使得各個同事對象獨立而易於複用。
然而,中介者模式也存在對應的缺點:
1)中介者模式中,中介者角色承擔了較多的責任,因此一旦這個中介者對象出現了問題,整個系統將會受到重大的影響。例如,QQ遊戲中計算歡樂豆的程序出錯了,這樣會形成重大的影響。
2)新增長一個同事類時,不得不去修改抽象中介者類和具體中介者類,此時可使用觀察者模式和狀態模式來解決這個問題。
5、 總結
中介者模式,定義了一箇中介對象來封裝系列對象之間的交互。中介者使各個對象不須要顯式地相互引用,從而使其耦合性下降,並且能夠獨立地改變它們之間的交互。中介者模式通常應用於一組定義良好的對象之間須要進行通訊的場合,以及想定製一個分佈在多個類中的行爲,而又不想生成太多的子類的情形下。