行为型模式之中介者模式

中介者模式(Mediator Pattern)是用来降低多个对象和类之间的通信复杂性.这种模式提供了一个中介类,该类通常处理不同类之间的通信,并支持松耦合,使代码易于维护.中介者模式属于行为型模式。

世界在二次大战之后总体是和平的,但还是有不少战争,比如伊拉克战争,伊朗核问题,朝鲜核问题等,由于各国之间代表的利益不同,所以矛盾冲突是难免的,但如果有这么一个组织由各国的代表组成,用来维护国际和平与安全,解决国际间经济,社会,文化和人道主义性质的问题,不是很好吗?大家肯定想到了就是联合国组织,对,在这里它就是一个调停者,中介者的角色

仔细分析一下,国与国之间的关系,就类似于不同的对象与对象之间的关系,这就要求对象之间需要知道其他所有的对象,尽管将一个系统分割成许多对象通常可以增加其可复用性,但是对象见相互链接的激增又会降低其可复用性.为什么会这样呢?大量的连接使得一个对象不可能在没有其他对象的支持下工作,系统表现为一个不可分割的整体,所以,对系统的行为进行任何较大的改动就十分困难了.

根据"迪米特法则",如果两个类之间不必彼此直接通信,那么这两个类就不应该发生直接的相互作用.如果其中一个类需要调用另一个类的某一个方法的话,可以通过第三者转发这个调用.比如国与国之间完全可以通过’联合国’这个中介者来发生关系,而不同直接通信

从上图可以看出,如果各个对象相互通信,会构成网状结构,如果通过中介者对象,可以将系统的网状结构变成以中介者为中心的星形结构,每个具体对象不再通过直接的联系与另一个对象发生相互作用,而是通过’中介者’对象与另一个对象发生相互作用.中介者对象的设计,使得系统的结构不会因为新对象对的引入造成大量的修改工作

对于中介对象而言，所有相互交互的对象，被视为同事类，中介对象就是来维护各个同事之间的关系，而所有的同事类都只是和中介对象交互。

每个同事对象，当自己发生变化的时候，不需要知道这会引起其它对象有什么变化，它只需要通知中介者就可以了，然后由中介者去与其它对象交互。这样松散耦合带来的好处是，除了让同事对象之间相互没有关联外，还有利于功能的修改和扩展。
有了中介者过后，所有的交互都封装到中介者对象里面，各个对象就不再需要维护这些关系了。扩展关系的时候也只需要扩展或修改中介者对象就可以了。

模式结构和说明

Mediator:中介者接口.在里面定义各个同事之间交互需要的方法,可以是公共的通讯方法,比如changed方法，大家都用，也可以是小范围的交互方法。
ConcreteMediator:具体中介者实现对象.它需要了解并维护各个同事对象,并负责具体的协调各同事对象的交互关系
Colleague：同事类的定义，通常实现成为抽象类，主要负责约束同事对象的类型，并实现一些具体同事类之间的公共功能，比如：每个具体同事类都应该知道中介者对象，也就是具体同事类都会持有中介者对象，就可以定义到这个类里面。
ConcreteColleague：具体的同事类，实现自己的业务，在需要与其它同事通讯的时候，就与持有的中介者通信，中介者会负责与其它的同事交互。

示例代码

案例:聊天室消息发送

1. 定义抽象同事类

//抽象同事类
@interface Colleague : NSObject
/**/
@property (nonatomic,strong) Mediator *mediator;

+ (Colleague *)colleageWithMediator:(Mediator *)mediator;

- (void)sendMessage:(NSString *)message;

- (void)notifyMessage:(NSString *)message;

@end

2. 定义抽象中介者类

//抽象同事类(定义同事对象到中介者对象的接口)
@interface Mediator : NSObject

- (void)sendMessage:(NSString *)message colleague:(Colleague *)colleague;

@end

3. 定义具体同事类

@implementation ConcreteColleague1

- (void)sendMessage:(NSString *)message
{
    NSLog(@"同事1发送消息:%@",message);
    [self.mediator sendMessage:message colleague:self];
}

- (void)notifyMessage:(NSString *)message
{
    NSLog(@"同事1得到消息:%@",message);
}

@end

@implementation ConcreteColleague2
- (void)sendMessage:(NSString *)message
{
    NSLog(@"同事2发送消息:%@",message);
    [self.mediator sendMessage:message colleague:self];
}

- (void)notifyMessage:(NSString *)message
{
    NSLog(@"同事2得到消息:%@",message);
}

@end

具体同事类实现自己的行为
4. 定义具体中介者类(知道所有的同事类,并从具体同事接收消息,并向具体同事对象发送命令)

//具体中介者对象
@interface ConcreteMediator : Mediator
/**/
@property (nonatomic,strong) ConcreteColleague1 *colleague1;
/**/
@property (nonatomic,strong) ConcreteColleague2 *colleague2;

@end
- (void)sendMessage:(NSString *)message colleague:(Colleague *)colleague
{
    if ([colleague isEqual:self.colleague1]) {
        [self.colleague2 notifyMessage:message];
    } else {
        [self.colleague1 notifyMessage:message];
    }
}

5. 客户端实践
   先定义中介者对象,然后定义所有的同事类,绑定到中介者对象上

    ConcreteMediator *mediator = [[ConcreteMediator alloc] init];
    ConcreteColleague1 *c1 = (ConcreteColleague1 *)[ConcreteColleague1 colleageWithMediator:mediator];
    ConcreteColleague2 *c2 = (ConcreteColleague2 *)[ConcreteColleague2 colleageWithMediator:mediator];
    
    mediator.colleague2 = c2;
    mediator.colleague1 = c1;
    
    [c1 sendMessage:@"吃饭了吗"];
    [c2 sendMessage:@"没有呢?你打算请客吗"];

从上图可以看出,同事1和同事2并没有直接通信,对方却受到消息,给它们传递的正式中介者

模式讲解

1. 模式的功能
   中介者的功能非常简单,就是封装对象之间的交互,如果一个对象的操作会引起其他相关对象的变化,或者是某个操作小引起其他对象的后续或者连带操作,而这个对象有不希望自己来处理这些关系,那么久可以找中介者,把所有的麻烦扔给它，只在需要的时候通知中介者，其它的就让中介者去处理就可以了。
   反过来，其它的对象在操作的时候，可能会引起这个对象的变化，也可以这么做。最后对象之间就完全分离了，谁都不直接跟其它对象交互，那么相互的关系，全部被集中到中介者对象里面了，所有的对象就只是跟中介者对象进行通信，相互之间不再有联系。

   把所有对象之间的交互都封装在中介者当中，无形中还得到另外一个好处，就是能够集中的控制这些对象的交互关系，这样有什么变化的时候，修改起来就很方便。

2. 同事与中介者的关系
   在中介者模式中，当一个同事对象发生了改变，需要主动通知中介者，让中介者去处理与其它同事对象相关的交互。
   这就导致了同事对象和中介者对象之间必须有关系，首先是同事对象需要知道中介者对象是谁；反过来，中介者对象也需要知道相关的同事对象，这样它才能与同事对象进行交互。也就是说中介者对象和同事对象之间是相互依赖的。

3. 优点

   • 中介者模式通过把多个同事对象之间的交互封装到中介者对象里面,从而使得同事对象之间松散耦合,基本上可以做到互不依赖,这样一来,同事对象就可以独立的变化和复用,而不再像以前那样"牵一发而动全身"
   • 多个同事对象的交互，被封装在中介者对象里面集中管理，使得这些交互行为发生变化的时候，只需要修改中介者对象就可以了，当然如果是已经做好的系统，那就扩展中介者对象，而各个同事类不需要做修改。
   • 没有使用中介者模式的时候，同事对象之间的关系通常是多对多的，引入中介者对象过后，中介者对象和同事对象的关系通常变成了双向的一对多，这会让对象的关系更容易理解和实现。

4. 缺点
   如果同事对象的交互非常多，而且比较复杂，当这些复杂性全部集中到中介者的时候，会导致中介者对象变得十分的复杂，而且难于管理和维护。

在iOS中的常用场景(控制器切换)

需求描述：在一个根视图控制器中(暂且称之为rootVC)，点击不同的按钮，跳到对应的视图控制器，分别是firstVC、secondVC、thirdVC。

传统做法策略图:

从图中看到，这样的处理方式繁乱复杂，不够清晰，当控制器VC数量非常多时，更加难以维护。

中介者模式策略图

从图中可以直观感受到，处理方式简洁明了。Mediator类的作用就相当于一个路由器，将客户发起的URL请求转移到对应的类。具体写法挺简单的,大家可以试试,如有需要,私聊我

Demo地址