# C#設計模式(18)——中介者模式（Mediator Pattern） ## 一、引言 在現實生活中，有很多中介者模式的身影，例如QQ游戲平臺，聊天室、QQ群和短信平臺，這些都是中介者模式在現實生活中的應用，下面就具體分享下我對中介者模式的理解。 ## 二、 中介者模式的介紹 ## 2.1 中介者模式的定義 從生活中的例子可以看出，不論是QQ游戲還是QQ群，它們都是充當一個中間平臺，QQ用戶可以登錄這個中間平臺與其他QQ用戶進行交流，如果沒有這些中間平臺，我們如果想與朋友進行聊天的話，可能就需要當面才可以了。電話、短信也同樣是一個中間平臺，有了這個中間平臺，每個用戶都不要直接依賴與其他用戶，只需要依賴這個中間平臺就可以了，一切操作都由中間平臺去分發。了解完中介模式在生活中的模型后，下面給出中介模式的正式定義。 中介者模式，定義了一個中介對象來封裝一系列對象之間的交互關系。中介者使各個對象之間不需要顯式地相互引用，從而使耦合性降低，而且可以獨立地改變它們之間的交互行為。 ## 2.2 中介者模式的結構 從生活中例子自然知道，中介者模式設計兩個具體對象，一個是用戶類，另一個是中介者類，根據針對接口編程原則，則需要把這兩類角色進行抽象，所以中介者模式中就有了4類角色，它們分別是：抽象中介者角色，具體中介者角色、抽象同事類和具體同事類。中介者類是起到協調各個對象的作用，則抽象中介者角色中則需要保存各個對象的引用。有了上面的分析，則就不難理解中介者模式的結構圖了，具體結構圖如下所示：  **為什么要使用中介者模式** 在現實生活中，中介者的存在是不可缺少的，如果沒有了中介者，我們就不能與遠方的朋友進行交流了。而在軟件設計領域，為什么要使用中介者模式呢？如果不使用中介者模式的話，各個同事對象將會相互進行引用，如果每個對象都與多個對象進行交互時，將會形成如下圖所示的網狀結構。  從上圖可以發現，如果不使用中介者模式的話，每個對象之間過度耦合，這樣的既不利于類的復用也不利于擴展。如果引入了中介者模式，那么對象之間的關系將變成星型結構，采用中介者模式之后會形成如下圖所示的結構：  從上圖可以發現，使用中介者模式之后，任何一個類的變化，只會影響中介者和類本身，不像之前的設計，任何一個類的變化都會引起其關聯所有類的變化。這樣的設計大大減少了系統的耦合度。 ## 2.3 中介者模式的實現 介紹完中介者模式的定義和存在的必要性后，下面就以現實生活中打牌的例子來實現下中介者模式。在現實生活中，兩個人打牌，如果某個人贏了都會影響到對方狀態的改變。如果此時不采用中介者模式實現的話，則上面的場景的實現如下所示： ``` 1 // 抽象牌友類 2 public abstract class AbstractCardPartner 3 { 4 public int MoneyCount { get; set; } 5 6 public AbstractCardPartner() 7 { 8 MoneyCount = 0; 9 } 10 11 public abstract void ChangeCount(int Count, AbstractCardPartner other); 12 } 13 14 // 牌友A類 15 public class ParterA : AbstractCardPartner 16 { 17 public override void ChangeCount(int Count, AbstractCardPartner other) 18 { 19 this.MoneyCount += Count; 20 other.MoneyCount -= Count; 21 } 22 } 23 24 // 牌友B類 25 public class ParterB : AbstractCardPartner 26 { 27 public override void ChangeCount(int Count, AbstractCardPartner other) 28 { 29 this.MoneyCount += Count; 30 other.MoneyCount -= Count; 31 } 32 } 33 34 class Program 35 { 36 // A,B兩個人打牌 37 static void Main(string[] args) 38 { 39 AbstractCardPartner A = new ParterA(); 40 A.MoneyCount = 20; 41 AbstractCardPartner B = new ParterB(); 42 B.MoneyCount = 20; 43 44 // A 贏了則B的錢就減少 45 A.ChangeCount(5, B); 46 Console.WriteLine("A 現在的錢是：{0}", A.MoneyCount);// 應該是25 47 Console.WriteLine("B 現在的錢是：{0}", B.MoneyCount); // 應該是15 48 49 // B贏了A的錢也減少 50 B.ChangeCount(10, A); 51 Console.WriteLine("A 現在的錢是：{0}", A.MoneyCount); // 應該是15 52 Console.WriteLine("B 現在的錢是：{0}", B.MoneyCount); // 應該是25 53 Console.Read(); 54 } 55 } ``` 上面確實完美解決了上面場景中的問題，并且使用了抽象類使具體牌友A和牌友B都依賴于抽象類，從而降低了同事類之間的耦合度。但是這樣的設計，如果其中牌友A發生變化時，此時就會影響到牌友B的狀態，如果涉及的對象變多的話，這時候某一個牌友的變化將會影響到其他所有相關聯的牌友狀態。例如牌友A算錯了錢，這時候牌友A和牌友B的錢數都不正確了，如果是多個人打牌的話，影響的對象就會更多。這時候就會思考——能不能把算錢的任務交給程序或者算數好的人去計算呢，這時候就有了我們QQ游戲中的歡樂斗地主等牌類游戲了。所以上面的設計，我們還是有進一步完善的方案的，即加入一個中介者對象來協調各個對象之間的關聯，這也就是中介者模式的應用了，具體完善后的實現代碼如下所示： ``` 1 namespace MediatorPattern 2 { 3 // 抽象牌友類 4 public abstract class AbstractCardPartner 5 { 6 public int MoneyCount { get; set; } 7 8 public AbstractCardPartner() 9 { 10 MoneyCount = 0; 11 } 12 13 public abstract void ChangeCount(int Count, AbstractMediator mediator); 14 } 15 16 // 牌友A類 17 public class ParterA : AbstractCardPartner 18 { 19 // 依賴與抽象中介者對象 20 public override void ChangeCount(int Count, AbstractMediator mediator) 21 { 22 mediator.AWin(Count); 23 } 24 } 25 26 // 牌友B類 27 public class ParterB : AbstractCardPartner 28 { 29 // 依賴與抽象中介者對象 30 public override void ChangeCount(int Count, AbstractMediator mediator) 31 { 32 mediator.BWin(Count); 33 } 34 } 35 36 // 抽象中介者類 37 public abstract class AbstractMediator 38 { 39 protected AbstractCardPartner A; 40 protected AbstractCardPartner B; 41 public AbstractMediator(AbstractCardPartner a, AbstractCardPartner b) 42 { 43 A = a; 44 B = b; 45 } 46 47 public abstract void AWin(int count); 48 public abstract void BWin(int count); 49 } 50 51 // 具體中介者類 52 public class MediatorPater : AbstractMediator 53 { 54 public MediatorPater(AbstractCardPartner a, AbstractCardPartner b) 55 : base(a, b) 56 { 57 } 58 59 public override void AWin(int count) 60 { 61 A.MoneyCount += count; 62 B.MoneyCount -= count; 63 } 64 65 public override void BWin(int count) 66 { 67 B.MoneyCount += count; 68 A.MoneyCount -= count; 69 } 70 } 71 72 class Program 73 { 74 static void Main(string[] args) 75 { 76 AbstractCardPartner A = new ParterA(); 77 AbstractCardPartner B = new ParterB(); 78 // 初始錢 79 A.MoneyCount = 20; 80 B.MoneyCount = 20; 81 82 AbstractMediator mediator = new MediatorPater(A, B); 83 84 // A贏了 85 A.ChangeCount(5, mediator); 86 Console.WriteLine("A 現在的錢是：{0}", A.MoneyCount);// 應該是25 87 Console.WriteLine("B 現在的錢是：{0}", B.MoneyCount); // 應該是15 88 89 // B 贏了 90 B.ChangeCount(10, mediator); 91 Console.WriteLine("A 現在的錢是：{0}", A.MoneyCount);// 應該是15 92 Console.WriteLine("B 現在的錢是：{0}", B.MoneyCount); // 應該是25 93 Console.Read(); 94 } 95 } 96 } ``` 從上面實現代碼可以看出，此時牌友A和牌友B都依賴于抽象的中介者類，這樣如果其中某個牌友類變化只會影響到，只會影響到該變化牌友類本身和中介者類，從而解決前面實現代碼出現的問題，具體的運行結果和前面實現結果一樣，運行結果如下圖所示：  在上面的實現代碼中，抽象中介者類保存了兩個抽象牌友類，如果新添加一個牌友類似時，此時就不得不去更改這個抽象中介者類。可以結合觀察者模式來解決這個問題，即抽象中介者對象保存抽象牌友的類別，然后添加Register和UnRegister方法來對該列表進行管理，然后在具體中介者類中修改AWin和BWin方法，遍歷列表，改變自己和其他牌友的錢數。這樣的設計還是存在一個問題——即增加一個新牌友時，此時雖然解決了抽象中介者類不需要修改的問題，但此時還是不得不去修改具體中介者類，即添加CWin方法，我們可以采用狀態模式來解決這個問題，關于狀態模式的介紹將會在下一專題進行分享。 ## 三、中介者模式的適用場景 一般在以下情況下可以考慮使用中介者模式： * 一組定義良好的對象，現在要進行復雜的相互通信。 * 想通過一個中間類來封裝多個類中的行為，而又不想生成太多的子類。 ## 四、中介者模式的優缺點 **中介者模式具有以下幾點優點：** * 簡化了對象之間的關系，將系統的各個對象之間的相互關系進行封裝，將各個同事類解耦，使得系統變為松耦合。 * 提供系統的靈活性，使得各個同事對象獨立而易于復用。 **然而，中介者模式也存在對應的缺點：** * 中介者模式中，中介者角色承擔了較多的責任，所以一旦這個中介者對象出現了問題，整個系統將會受到重大的影響。例如，QQ游戲中計算歡樂豆的程序出錯了，這樣會造成重大的影響。 * 新增加一個同事類時，不得不去修改抽象中介者類和具體中介者類，此時可以使用觀察者模式和狀態模式來解決這個問題。