提供一个中介对象出来,用于封装一系列对象的交互,从而使各对象不须要直接交互,进一步下降了对象间的耦合度。这是一种行为型设计模式。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领域驱动中,服务层与领域对象的交互就是一个很是稳定的场景,在这个场景里中介者模式获得了比较普遍的运用。