1、应用场景

谈到中介者模式这个词，我马上就想到了cocos2d-x里面的CCDirector类。这个类除了应用了单例模式，还应用了中介者模式。Why？因为它封装了Scheduler、ActionManager、TouchDispatcher、KeypadDispatcher和Accelerometer这五个对象的交互。它使得这几个对象之间的交互不需要显式地相互引用，使其耦合度变低。当然更多的是使得我们游戏中的对象可以方便地与这些类进行交互，而不需要显式地引用这些类。同时，由于Director类被设计成单例类，这样更加方便了客户程序调用。

由于之前Scheduler、ActionManager、TouchDispatcher这些类都被设计成了单例类，现在通过Director这个中介类，减少了系统中单例的数目，同时也使得这些类获得了单例的属性。（唯一实例和全局访问点都靠Director类来保障，这也是我为什么在介绍单例模式的时候讲过一句话“至少需要一个单例模式”的原因，因为其它“单例”可以通过此单例也获得“单例的属性”）

补充：我这里介绍的Director的应用场景，跟GoF标准中介者设计模式存在一定出入，但是，我觉得某些思想是相通的。GoF中提到的中介者模式的本质是“封装交互”，这一点在Director类中并没有体现出来。我这里冒然将二者联系在一起，实属认识上的不足，可能得了所谓的“模式病”吧。大家注意区分一下就行啦。所以，我感觉有时候设计思想比模式本身更重要，希望我尽快修成正果。

2、使用该模式的优缺点

优点：

1）、把多个同事对象的交互封装到一个中介者对象中，使得同事对象之间松散耦合，互不依赖

2）、集中控制交互

3）、多对多变成了一对多

缺点：

1）、容易造成中介者对象变成巨无霸类，维护和修改变得更加困难

3、模式定义及一般实现

定义：

用一个中介对象来封装一系列的对象交互。中介者使得各对象不需要显式地相互引用，从而使其松散耦合，而且可以独立地改变它们之间的交互。

UML图：

一般实现：参考wikipedia

4、游戏开发中如何运用此模式

游戏世界里的对象关系非常复杂，如果设计得不好，极容易形成强耦合。而游戏天生又是需要经常更新、修改bug和升级的，这就导致了游戏程序的维护和扩展非常地难。使用中介者模式可以减少游戏世界里面对象之间的多对多关系，使之转变成多对一的关系。

关于中介者的实现，可以把AppDelegate类设计成中介者对象，也可以自定义中介者对象，比如GameManager类。把此类设计成单例类，可以方便访问，同时，此类可以拥有像gameScene，levelSaver等类的引用，方便其它对象与这些对象进行交互。

5、与其它模式的关系

中介者模式的实现可以采用单例模式，参考Director的实现。同时，在处理同事对象之间的交互的时候，可以采用观察者模式。