入門設計模式之中介者模式 十八

2021-10-02 00:17:01 字數 3914 閱讀 7889

物件類與物件類之間的互動通訊統一由另外乙個中介類來控制 ,物件通過中介類對其他物件互動,中介類起著控制器的作用。

優點:降低類與類之間的耦合性,物件與物件之間不再相互引用,把類與類之間的互動抽離出來方便擴充套件。

缺點:關係過於複雜的話,如物件與物件類互動功能比較多時,中介類將異常龐大,不利於後期維護。

實現房東與租客2個人之間的交流,主要有說話和聆聽。

都不考慮設計了,直接擼**。

3個類,

person.cs  -人基類  

landlord.cs  -房東類  

tenant.cs  -租客類

// 人基類

public class person

public virtual void talk(person person, string str)

public virtual void listen(person person, string str)

}//房東類

public class landlord : person

public override void talk(person person, string str)

public override void listen(person person, string str)

}//租客類

public class tenant : person

public override void talk(person person, string str)

public override void listen(person person, string str)

}//客戶端呼叫

public static void main(string args)

執行結果

小結:每次房東或者租客要說話時,都得把接收者物件傳遞過去,在說話方法時呼叫接收物件的listen方法,此處為耦合部分。

通過新增乙個中介,房東與租客的通話都交給他來處理,這樣房東與租客就不需要互相認識再去溝通了。

5個類,

person.cs  -人基類  

landlord.cs  -房東類  

tenant.cs  -租客類

mediator   -中介者基類

playermediator  -中介類實現

// 人基類

public class person

public void setmediator(mediator m)

public virtual void talk(string str)

public virtual void listen(person person, string str)

}//房東類

public class landlord : person

public override void talk(string str)

public override void listen(person person, string str)

}//租客類

public class tenant : person

public override void talk(string str)

public override void listen(person person, string str)

}//中介基類

public abstract class mediator

//中介者具體實現

public class playermediator : mediator

public void setlandlord(landlord l)

//根據傳過來的物件來決定接收者

public override void listen(person person, string str)

else if (person == landlord)

}}//客戶端呼叫

public static void main(string args)

執行結果

小結:房東與租客在說話時不需要在他talk裡去處理呼叫接收者的listent方法了,而是由其持有的中介物件playermediator去處理這些事,解耦步驟就在這點上,剝離了與接收者的listent通訊,雖然客戶端呼叫的步驟多了一些賦值步驟,但是物件導向就是這樣, 不要介意這個,還是很穩的放心。

通過學習,我們了解到了中介者模式的應用,我們把剛剛的實現方式畫出來。

(1)需求:班長通知訊息給每乙個同學。

(2)分析:按照笨方法,班長得走到每乙個人面前跟他說一遍,有幾個人就得說幾次,也就是班長類得呼叫無數次talk方法然後依次傳入每乙個同學類物件,當不只是班長發言,假如2個同學要說悄悄話了,那麼就變成了這樣:,如下圖。

為了解決這個問題,我們引入了交流工具qq,變成如下:

這樣是不是清晰多了,這裡的qq就是我們的中介物件。

(3)實現**:

5個類,

student.cs  -學生基類  

banzhang.cs  -班長類 

tongxue.cs  -學生類

mediator   -中介者基類

qqmediator  -中介qq類實現

// 學生基類

public class student

public void setmediator(mediator m)

//在群裡說話

public virtual void talkall(string str)

//跟乙個人私聊,引數為私聊物件

public virtual void talkone(student student, string str)

public virtual void listen(student student, string str)

}//班長類

public class banzhang : student

}//同學類

public class tongxue : student

}//中介基類

public abstract class mediator

//中介者qq具體實現

public class qqmediator : mediator

//新增人員到qq

public void addstudent(params student s)

//群聊

public override void talkall(student talkman, string str)}}

}//私聊

public override void talkone(student talkman, student listentman, string str)

}}//客戶端呼叫

public static void main(string args)

執行結果:

設計模式之中介者模式

1 抽象中介者,mediator 抽象中介 author jin.li public abstract class mediator2 具體的中介者,主機板 主機板中介 author jin.li public class mainboard extends mediator if colleagu...

設計模式之中介者模式

中介者模式 假如沒有總經理,下面六個個部門,財務部 市場部 研發部,財務部要發工資,讓大家核對公司需要跟市場部和研發部都通氣,市場部要接個新專案,需要研發部門處理技術,需要財務部出資金,市場部跟各個部門打交道,雖然只有六個個部門,但是關係非常亂 實際上,公司有總經理,各個部門有什麼事情都通報給總結裡...

設計模式之中介者模式

嘮叨幾句 設計模式的案例我已經寫過大部分的案例,但是本人沒有經常寫部落格的習慣,最近在將本人之前在碼雲上的案例直接搬過來 個人感覺容易和外觀模式弄混,所以在這裡做下簡單的比較 外觀模式 本質封裝互動,組合呼叫。就是向外部提供一組功能,但是具體的實現比較複雜,內部有喝多的元件相互組合呼叫,強調的是外觀...