JAVA设计模式—中介者模式(Mediator)

场景问题

         大家都知道，电脑里面各个配件之间的交互，主要是通过主板来完成的(事实上主板有很多的功能，这里不去讨论)。试想一下，如果电脑里面没有主板，会怎么样呢？

         如果电脑里面没有主板，那么各个配件之间就必须自行相互交互，以互相传递数据。理论上说，基本上各个配件相互之间都存在交互数据的可能，如图10.1所示。

        这也太复杂了吧，这还没完呢，由于各个配件的接口不同，那么相互之间交互的时候，还必须把数据接口进行转换才能匹配上，那就更恐怖了。

所幸是有了主板，各个配件的交互完全通过主板来完成，各个配件都只需要和主板交互，而主板知道如何和所有的配件打交道，那就简单很多了，这就避免了如果10.1所描述的那样乱作一团。有了主板后的结构如果10.2所示：

        如果上面的情况发生在软件开发上呢？

       若把每个电脑配件都抽象成为一个类或者是子系统，那就相当于出现了多个类直接相互交互，而且交互很繁琐，导致每个类都必须知道所有需要交互的类，也就是我们常说的类和类耦合了，是不是很麻烦？

       在软件开发中出现这种情况可就不妙了，不但开发的时候每个类会很复杂，因为要兼顾其他的类，更要命的是每个类在发生改动的时候，需要通知所有相关的类一起修改，因为接口或者是功能发生了变动，使用它的地方都得变，快要疯了吧！

       那该如何来简化这种多个对象之间的交互呢？

解决方案

       用来解决上述问题的一个合理的解决方案就是中介者模式(Mediator)。那么什么是中介者模式呢？

1、中介者模式的定义

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

2、应用中介者模式来解决问题的思路

       仔细分析上面的问题，根本原因就在于多个对象需要相互交互，从而导致对象之间紧密耦合，不利于对象的修改和维护。

       中介者模式的解决思路很简单，跟电脑的例子一样，中介者通过引入一个中介对象，让其他的对象都只和中介对象交互，而且中介对象知道如何和其他所有的对象交互，这样对象之间的交互关系就没有了，从而实现了对象之间的解耦。

中介者模式的结构和说明

       中介者模式的结构如图10.3所示：

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

中介者模式示例代码

1、先来看看所有同事的父类的定义。

        按照前面的描述，所有需要交互的对象都被视为同事类，这些同事类，这些同事类应该有一个统一的约束。而且所有的同事类都需要和中介者对象交互，换句话说就是所有的同事都应该持有中介者对象。

        因此，为了统一约束众多的同事类，并为同事类提供持有中介者对象的公共功能，先来定义一个抽象的同事类，在里面实现持有中介者对象的公共功能。