提供一箇中介對象出來,用於封裝一系列對象的交互,從而使各對象不須要直接交互,進一步下降了對象間的耦合度。這是一種行爲型設計模式。html
因而可知,中介者模式主要解決的是對象間所存在的大量關係,咱們都知道,對象間一旦關聯緊密,必然會致使系統的複雜性增長,一旦某個對象有所修改,其關聯對象也有可能會有跟着更改,這天然不是咱們所但願的。有些朋友可能會說,若是交互不少,是否是能夠將對象合併,從某種角度上來講,咱們能夠考慮對象合併。可是,咱們並不能這樣去作,由於對象存在的層級多是不一樣的,有些是處理數據交互的,有些是處理業務級的,合併起來會致使系統層次不明,引入更大的風險。程序員
在現實生活中,中介者更多的體現爲調度平臺或者房產中介,再或者就是紅娘了。咱們以紅娘爲例,設計模式
程序員找個女友實在是太難,並且時間也很少,圈子也不大,一個一個去認識,鬼知道哪個要找對象的,耗費精力不說,尼瑪,還少敲了好幾段代碼。因此,通常經過紅娘會更方便一點,會使得咱們的目的更加明確,就是找對象,篩選、信息收集、匹配的事情交給紅娘作就行了。畢竟紅娘但是掌握着不少女孩子的信息及其擇偶要求的,程序員過去把信息或者要求填寫一下便可,紅娘幫你匹配合適的女孩子,一旦有較高的匹配度,就能夠約會見見了,說不許很快就成了,這樣代碼沒少敲,對象也不耽誤找,是否是很爽……ide
以上,咱們能夠發現,在中介者模式裏面,中介者承擔的職能主要包括:this
- 業務通道的聚合,把以前繁瑣的對象交互抽象出來,全部的交互經過中介者通道進行。
- 信息的中轉,在中介者模式裏,對象間的信息經過中介者轉發到對應的對象處。
UML描述的是程序員相親的例子spa
經過以上UML圖,咱們能夠知道,中介者模式主要有如下幾個角色設計
Mediator: 抽象中介者。定義了同事對象與中介者對象進行交互的接口。3d
ConcreteMediator: 具體中介者,實現抽象中介者的方法。code
Colleague: 抽象同事類。htm
ConcreteColleague: 具體同事類。每一個具體同事類都只須要知道本身的行爲便可,他們是直接與中介者打交道的類。
接下來咱們以程序員找對象爲例,這裏的中介者就是程序員與妹子之間協調的紅娘了,來看看如何經過代碼編寫
核心邏輯代碼:
1: /// <summary>
2: /// 抽象中介者
3: /// </summary>
4: public abstract class Mediator
5: {
6: /// <summary>
7: /// 相親
8: /// </summary>
9: public abstract void BlindDate(Colleague colleague, string msg);
10: }
11:
12: /// <summary>
13: /// 抽象同事類
14: /// </summary>
15: public abstract class Colleague
16: {
17: protected Mediator mediator;
18: protected string msg;
19:
20: public Colleague(Mediator mediator, string msg)
21: {
22: this.mediator = mediator;
23: this.msg = msg;
24: }
25:
26: public abstract void Communication(string msg);
27: }
28:
29: /// <summary>
30: /// 媒婆或者說是紅娘
31: /// </summary>
32: /// <seealso cref="ConsoleApp2.Colleague" />
33: public class Matchmaker : Colleague
34: {
35: public Matchmaker(Mediator mediator, string msg) : base(mediator, msg)
36: {
37: }
38:
39: public void BlindDate()
40: {
41: this.mediator.BlindDate(this, this.msg);
42: }
43:
44: public override void Communication(string msg)
45: {
46: Console.WriteLine(this.msg + ":" + msg);
47: }
48: }
49:
50: /// <summary>
51: /// 相親者
52: /// </summary>
53: /// <seealso cref="ConsoleApp2.Colleague" />
54: public class Programmer : Colleague
55: {
56: public Programmer(Mediator mediator, string msg) : base(mediator, msg)
57: {
58: }
59:
60: public void BlindDate()
61: {
62: this.mediator.BlindDate(this, this.msg);
63: }
64:
65: public override void Communication(string msg)
66: {
67: Console.WriteLine(this.msg + ":" + msg);
68: }
69: }
70:
71: /// <summary>
72: /// 這裏就是中介機構了,暫且叫作結婚吧,做爲一箇中介結構,裏面的信息是徹底的
73: /// </summary>
74: /// <seealso cref="ConsoleApp2.Mediator" />
75: public class MarryMediator : Mediator
76: {
77: public override void BlindDate(Colleague colleague, string msg)
78: {
79: colleague.Communication(msg);
80: }
81: }
1: class Program
2: {
3: static void Main(string[] args)
4: {
5: Mediator mediator = new MarryMediator();
6:
7: //紅娘
8: Matchmaker matchmaker = new Matchmaker(mediator, "金牌紅娘");
9: //程序員
10: Programmer programmer = new Programmer(mediator, "光棍程序員");
11:
12: mediator.BlindDate(matchmaker, "請問你是要相親嗎,咱們這邊的優質女生有不少");
13: mediator.BlindDate(programmer, "是的,幫我介紹一個溫柔賢惠的妹子吧");
14:
15: Console.Read();
16: }
17: }
運行結果:
就這樣,讓人期待已久的相親開始了,後面的事情,就交給程序員本身發揮了
優勢:
中介者模式簡化並理清了對象間的關係,下降了類自己的複雜度,鬆散了對象間的耦合
缺點:
中介者自己承擔着太過沉重的職責,以致於中介者掛掉,可能系統也會掛掉
中介者模式,比較適合處理比較穩定的場景,對於一組定義比較良好的對象,預期可變性不是那麼強,想經過一箇中間類來封裝多個類中的行爲,而又不想生成太多的子類。 好比在DDD領域驅動中,服務層與領域對象的交互就是一個很是穩定的場景,在這個場景裏中介者模式獲得了比較普遍的運用。