【23种设计模式之】22.中介者模式

练习源码：https://github.com/liaoooyx/Design-Patterns

参考：http://c.biancheng.net/view/1393.html
https://www.cnblogs.com/chenssy/p/3348520.html
https://www.cnblogs.com/snaildev/p/7686908.html

中介者模式，定义了一个中介对象来封装一系列对象之间的交互关系。中介者使各个对象之间不需要显式地相互引用，从而使耦合性降低，而且可以独立地改变它们之间的交互行为。

在前面我就知道如果两个类不必彼此通信，那么这两个类就不应当发生直接关联的关系。如果其中一个类需要调用另一个类中的方法，我们可以通过第三方来转发这个调用。所以对于关系比较复杂的系统，我们为了减少对象之间的关联关系，使之成为一个松耦合系统，我们就需要使用中介者模式。

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

通过定义我们可以看出中介者主要是通过中介对象来封装对象之间的关系，使之各个对象在不需要知道其他对象的具体信息情况下通过中介者对象来与之通信。同时通过引用中介者对象来减少系统对象之间关系，提高了对象的可复用和系统的可扩展性。

但是就是因为中介者对象封装了对象之间的关联关系，导致中介者对象变得比较庞大，所承担的责任也比较多。它需要知道每个对象和他们之间的交互细节，如果它出问题，将会导致整个系统都会出问题。所以它比较容易应用也很容易误用。故当系统中出现了“多对多”交互复杂的关系群时，千万别急着使用中介者模式，你首先需要做的就是反思你的系统在设计上是不是合理。

个人理解
每一个同事类都持有同一个中介类的对象，当同事类需要与其他同事类通信时，则调用send()方法，send()方法内部调用Mediator类中的relay()方法，并将自身引用作为方法参数传递过去。

中介类持有所有具体同事类的对象。中介类的relay()方法内部预设逻辑判断，根据传入的Colleague子类型决定要将信息转发给谁。

另外，个人认为将Colleague同事换成Customer顾客更好理解