通俗易懂設計模式解析——中介者模式

前言

　　今天咱們一塊兒看看中介者模式，怎麼去理解這個模式呢？提及來也簡單、好理解。生活中咱們租房常常都是經過中介來實現的。通常租房要麼是房東直租要麼是中介。那麼今天要講的中介者模式和租房的這個中介是否有關係呢？固然是有點關係的。中介者模式是用來下降多個對象和類之間的通訊複雜性。這種模式提供了一箇中介類，這個類就來處理不一樣類之間的通信。租房中介也是這個道理。複製與各個房東和租戶之間的通信。將多對多簡化成了一對多的關係。咱們下面來具體看看究竟是怎麼回事吧!

中介者模式介紹

1、來由

在軟件系統中常常會遇到多個對象相互關聯相互引用依賴的狀況。這樣的話，若是遇到了需求變更將會影響到其餘各個相互關聯的對象變化。在這種狀況下，就須要一箇中介對象來管理處理這些多個對象之間的管理依賴關係。解決緊耦合、抵禦一動牽全身的變化。

2、意圖

用一箇中介對象來封裝一系列的對象交互，中介者使各對象不須要顯式地相互引用，從而使其耦合鬆散，並且能夠獨立地改變它們之間的交互。

3、案例圖

 

4、中介者模式代碼示例

看上面的案例圖，咱們一塊兒看看包含的四個部分：

抽象中介者：定義了各個同事之間交互須要的方法。

具體中介者：須要瞭解維護各個同事對象，而且負責協調各個具體同事之間的交互。

抽象同事類：約束具體同事類的類型、而且實現一些具體同事類之間的公共方法。

具體同事類：實現本身的業務。

咱們仍是回到開篇講到的那個例子。關於租房中介的例子。加入沒有租房中介。這裏有六個房東須要出租房屋，房屋各不相同、各有各的特色、適合不同的人租住。這六個房東之間恰好有點聯繫。而後都在出租房屋。這時租客A來租房，看了一號房東的房子不滿意、可是一號房東以爲可讓他去看看其餘五個朋友的房間。而後開始聯繫他的五個朋友。這樣運行下去好像有是沒有什麼問題的。可是其中二號房東若是房屋不出租或者出租出去了。也就是發生了變化。這是他則須要通知其餘五個朋友，告訴他們不用再給他介紹租客了。這裏就形成了中間一我的發生了變化，須要改動其餘五我的。那麼如何能夠解決這種狀況呢。咱們回到如今。把中介加進來、那六個房東都把房屋交給中介處理。租客A看房間一不滿意直接經過中介看房間二。當房間二被出租了。中介也只須要通知房東二號、而後他們簽定合同。下次還有人看房間就不會再看房間二了。這裏一個出現了變化也就影響改變了一個。並不會影響其餘另外五個房東。這個例子能夠更好的幫助咱們理解中介者模式。咱們下面看兩幅圖。

 

圖一：不採用中介的房東租房模式，多對多的網格。一動牽全身

 

圖二：採用中介的租房模式，一對多、一個變更不影響其餘

 

下面咱們看看代碼如何實現中介者模式的吧。

namespace Mediator_Pattern { class MediatorPattern { } /// <summary>
    /// 抽象中介者 /// </summary>
    public abstract class Mediator { /// <summary>
        /// 定義與同事間的交互通訊 /// </summary>
        public abstract void Common(string type); } /// <summary>
    /// 抽象同事類 /// </summary>
    public abstract class Colleague { /// <summary>
        /// 處理本身的事務（房東展現本身的房屋） /// </summary>
        public abstract void Handle(); } /// <summary>
    /// 房屋中介 /// </summary>
    public class HouseMediator : Mediator { /// <summary>
        /// 中介有全部房東的房屋信息 /// </summary>
        private SmallHouseColleague SmallHouse; private TwoHouseColleague TwoHouse; private ThreeHouseColleague ThreeHouse; public void SetSmallHouse(SmallHouseColleague small) { SmallHouse = small; } public void SetTwoHouse(TwoHouseColleague two) { TwoHouse = two; } public void SetThreeHouse(ThreeHouseColleague three) { ThreeHouse = three; } /// <summary>
        ///  
        /// </summary>
        /// <param name="colleague"></param>
        public override void Common(string type) { switch (type) { case "單間": SmallHouse.Handle(); Console.WriteLine("若是能夠就能夠租房了!"); break; case "兩居室": TwoHouse.Handle(); Console.WriteLine("若是能夠就能夠租房了!"); break; case "三居室": ThreeHouse.Handle(); Console.WriteLine("若是能夠就能夠租房了!"); break; default: Console.WriteLine($"{type}暫時沒有房源!"); break; } } } /// <summary>
    /// 房東（小房間） /// </summary>
    public class SmallHouseColleague : Colleague { /// <summary>
        /// 展現單間 /// </summary>
        public override void Handle() { Console.WriteLine( "單間——便宜整潔"); } } /// <summary>
    /// 房東（兩居室） /// </summary>
    public class TwoHouseColleague : Colleague { /// <summary>
        /// 展現兩居室 /// </summary>
        public override void Handle() { Console.WriteLine("兩居室——合適，靠譜"); } } /// <summary>
    /// 房東（三居室） /// </summary>
    public class ThreeHouseColleague : Colleague { /// <summary>
        /// 展現三居室 /// </summary>
        public override void Handle() { Console.WriteLine("三居室——大氣，寬鬆"); } } }

 

namespace Mediator_Pattern { class Program { static void Main(string[] args) { Console.WriteLine("一個租客看房："); ///初始化中介
            HouseMediator mediator = new HouseMediator(); ///初始化房屋信息
            SmallHouseColleague smallHouseColleague = new SmallHouseColleague( ); TwoHouseColleague twoHouseColleague = new TwoHouseColleague( ); ThreeHouseColleague threeHouseColleague = new ThreeHouseColleague( ); ///中介獲取房屋信息
 mediator.SetSmallHouse(smallHouseColleague); mediator.SetTwoHouse(twoHouseColleague); mediator.SetThreeHouse(threeHouseColleague); ///租戶A須要兩居室、提供看房
            mediator.Common("兩居室"); //租戶B須要四居室、暫無房源
            mediator.Common("四居室"); } } }

 

使用場景及優缺點

1、使用場景

一、系統中對象間存在較爲複雜引用，致使依賴關係和結構混亂而沒法複用的狀況。

二、想經過一箇中間類來封裝多個類的行爲，可是又不想要太多的子類。

2、優勢

一、鬆散耦合、將多個對象之間的聯繫緊耦合封裝到中介對象中，作到鬆耦合。不會致使一動牽全身。

二、將多個對象之間的交互聯繫集中在中介對象中。發送變化僅需修改中介對象便可、提供系統的靈活性、使同事對象獨立而易於複用。

三、符合迪米特原則。就是說一個對象應當對其餘對象有儘量少的瞭解。減小各個對象之間的瞭解。

3、缺點

1、若是各個同事間的交互很是多而且複雜狀況下，都交給中介者會致使中介者變得十分複雜，不易維護和管理。

總結

　　到這裏中介者模式就介紹完了。中介者模式主要是實現將多個對象的相互依賴和關聯解耦。用中介對象封裝一些列的對象交互。將多對多的相互轉換爲多對一的相互做用。咱們再回憶咱們以前所講到的外觀模式和代理模式。好像三者之間有一些類似之處。那麼咱們如何區分這三種模式呢？首先咱們看外觀模式—外觀模式注重的是簡化接口，簡化組件系統與外部程序的依賴關係。提供一個更高層次的統一接口，使子系統更加簡便的使用。代理模式—注重的是對其餘對象的訪問控制、傾向於的是一對一的關係處理。中介者模式—注重的是將多對多的關係處理封裝到一對多、經過一箇中介者對象對多個對象之間的依賴進行解耦。

---

　　  這個社會是存在不公平的，不要抱怨，由於沒有用！人老是在檢討中進步的！

 　　  C#設計模式系列目錄

　　   歡迎你們掃描下方二維碼，和我一塊兒踏上設計模式的闖關之路吧!