8.中介者模式 -Mediator

定义

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

结构和说明

 

Mediator：​

　　中介者接口。在里面定义各个同事之间交互须要的方法，能够是公共的通信方法，好比changed方法，你们都用，也能够是小范围的交互方法。

ConcreteMediator：

　　​ 具体中介者实现对象。它须要了解并维护各个同事对象，并负责具体的协调各同事对象的交互关系。

Colleague：

​ 　　同事类的定义，一般实现成为抽象类，主要负责约束同事对象的类型，并实现一些具体同事类之间的公共功能，好比：每一个具体同事类都应该知道中介者对象，也就是具体同事类都会持有中介者对象，就能够定义到这个类里面。

ConcreteColleague：​

　　具体的同事类，实现本身的业务，在须要与其它同事通信的时候，就与持有的中介者通讯，中介者会负责与其它的同事交互。

体会中介者模式

若是没有主板​ 若是电脑里面没有了主板，那么各个配件之间就必须自行相互交互，以互相传送数据，理论上说，基本上各个配件相互之间都存在交互数据的可能

 

有了主板，各个配件的交互彻底经过主板来完成，每一个配件都只须要和主板交互，而主板知道如何和全部的配件打交道，那就简单多了

存在的问题?

　　若是上面的状况发生在软件开发上呢？​

　　 若是把每一个电脑配件都抽象成为一个类或者是子系统，那就至关于出现了多个类之间相互交互，并且交互还很繁琐，致使每一个类都必须知道全部须要交互的类，也就是咱们常说的类和类耦合了，是否是很麻烦？

​ 　　这样一来，不但开发的时候每一个类会复杂，由于要兼顾其它的类，更要命的是每一个类在发生改动的时候，须要通知全部相关的类一块儿修改，由于接口或者是功能发生了变更，使用它的地方都得变，太可怕了吧！那该如何来简化这种多个对象之间的交互呢？

 

案例：

　　使用电脑来看电影​ 为了演示，考虑一个稍微具体点的功能。在平常生活中，咱们常用电脑来看电影，把这个过程描述出来，这里仅仅考虑正常的状况，也就是有主板的状况，简化后假定会有以下的交互过程：

　　1：首先是光驱要读取光盘上的数据，而后告诉主板，它的状态改变了

　　2：主板去获得光驱的数据，把这些数据交给CPU进行分析处理

　　3：CPU处理完后，把数据分红了视频数据和音频数据，通知主板，它处理完了

　　4：主板去获得CPU处理事后的数据，分别把数据交给显卡和声卡，去显示出视频和发出声音

​ 固然这是一个持续的、不断重复的过程，从而造成不间断的视频和声音，具体的运行过程不在讨论之列，假设就有如上简单的交互关系就能够了。也就是说想看电影，把光盘放入光驱，光驱开始读盘，就能够看电影了

使用模式的解决方案

理解中介者模式

1：中介者模式的功能​

　　中介者的功能很是简单，就是封装对象之间的交互。若是一个对象的操做会引发其它相关对象的变化，或者是某个操做须要引发其它对象的后续或连带操做，而这个对象又不但愿本身来处理这些关系，那么就能够找中介者，把全部的麻烦扔给它，只在须要的时候通知中介者，其它的就让中介者去处理就能够了。

​ 反过来，其它的对象在操做的时候，可能会引发这个对象的变化，也能够这么作。最后对象之间就彻底分离了，谁都不直接跟其它对象交互，那么相互的关系，所有被集中到中介者对象里面了，全部的对象就只是跟中介者对象进行通讯，相互之间再也不有联系。​ 把全部对象之间的交互都封装在中介者当中，无形中还获得另一个好处，就是可以集中的控制这些对象的交互关系，这样有什么变化的时候，修改起来就很方便。

2：须要Mediator接口吗

　　​ 有没有使用Mediator接口的必要，取决因而否会提供多个不一样的中介者实现。若是中介者实现只有一个的话，并且预计中也没有须要扩展的要求，那么就能够不定义Mediator接口，让各个同事对象直接使用中介者实现对象；若是中介者实现不仅一个，或者预计中有扩展的要求，那么就须要定义Mediator接口，让各个同事对象来面向中介者接口编程，而无需关心具体的中介者实现。

3：同事关系​

　　在中介者模式中，要求这些类都要继承相同的类，也就是说，这些对象从某个角度讲是同一个类型，算是兄弟对象。正是这些兄弟对象之间的交互关系很复杂，才产生了把这些交互关系分离出去，单独作成中介者对象，这样一来，这些兄弟对象就成了中介者对象眼里的同事。

4：同事和中介者的关系​

　　中介者对象和同事对象之间是相互依赖的 。

5：如何实现同事和中介者的通讯​

　　一种实现方式是在Mediator接口中定义一个特殊的通知接口，做为一个通用的方法，让各个同事类来调用这个方法 。另一种实现方式是能够采用观察者模式，把Mediator实现成为观察者，而各个同事类实现成为Subject，这样同事类发生了改变，会通知Mediator。Mediator在接到通知事后，会与相应的同事对象进行交互。

6：中介者模式的调用顺序示意图

 

广义中介者

标准的中介者模式在实际使用中的困难

1：是否有必要为同事对象定义一个公共的父类？​

　　你们都知道，Java是单继承的，为了使用中介者模式，就让这些同事对象继承一个父类，这是很很差的；再说了，这个父类目前也没有什么特别的公共功能，也就是说继承它也得不到多少好处。​ 在实际开发中，不少相互交互的对象自己是没有公共父类的，强行加上一个父类，会让这些对象实现起来特别别扭。

2：同事类有必要持有中介者对象吗？

　　​ 同事类须要知道中介者对象，以便当它们发生改变的时候，可以通知中介者对象，可是否须要做为属性，并经过构造方法传入，这么强的依赖关系呢？​ 也能够有简单的方式去通知中介对象，好比把中介对象作成单例，直接在同事类的方法里面去调用中介者对象。

3：是否须要中介者接口？​

　　 在实际开发中，很常见的状况是不须要中介者接口的，并且中介者对象也不须要建立不少个实例，由于中介者是用来封装和处理同事对象的关系的，它通常是没有状态须要维护的，所以中介者一般能够实现成单例。

4：中介者对象是否须要持有全部的同事？​

　　 虽然说中介者对象须要知道全部的同事类，这样中介者才能与它们交互。可是是否须要作为属性这么强烈的依赖关系，并且中介者对象在不一样的关系维护上，可能会须要不一样的同事对象的实例，所以能够在中介者处理的方法里面去建立、或者获取、或者从参数传入须要的同事对象。

5：中介者对象只是提供一个公共的方法，来接受同事对象的通知吗？​

　　从示例就能够看出来，在公共方法里，仍是要去区分究竟是谁调过来，这仍是简单的，尚未去区分究竟是什么样的业务触发调用过来的，由于不一样的业务，引发的与其它对象的交互是不同的。​ 所以在实际开发中，一般会提供具体的业务通知方法，这样就不用再去判断究竟是什么对象，具体是什么业务了。

对标准的中介者模式在实际使用中的改进

​ 基于上面的考虑，在实际应用开发中，常常会简化中介者模式，来使开发变得简单，好比有以下的简化：

1：一般会去掉同事对象的父类，这样可让任意的对象，只要须要相互交互，就能够成为同事；

2：还有一般不定义Mediator接口，把具体的中介者对象实现成为单例；

3：另一点就是同事对象再也不持有中介者，而是在须要的时候直接获取中介者对象并调用；中介者也再也不持有同事对象，而是在具体处理方法里面去建立、或者获取、或者从参数传入须要的同事对象。​ 把这样通过简化、变形使用的状况称为广义中介者。

广义中介者示例——部门与人员

1：部门和人员的关系 ： 是 多对多的

2：问题的出现想一想部门和人员的功能交互，举几个常见的功能：

（1）部门被撤销（2）部门之间进行合并（3）人员离职（4）人员从一个部门调职到另一个部门

想一想要实现这些功能，按照前面的设计，该怎么作呢？

（1）系统运行期间，部门被撤销了，就意味着这个部门不存在了，但是原来这个部门下全部的人员，每一个人员的所属部门中都有这个部门呢，那么就须要先通知全部的人员，把这个部门从它们的所属部门中去掉，而后才能够清除这个部门。

（2）部门合并，是合并成一个新的部门呢，仍是把一个部门并入到另外一个部门？若是是合并成一个新的部门，那么须要把原有的两个部门撤销，而后再新增一个部门；若是是把一个部门合并到另外一个部门里面，那就是撤销掉一个部门，而后把这个部门下的人员移动到这个部门。无论是那种状况，都面临着须要通知相应的人员进行更改这样的问题

（3）人员离职了，反过来就须要通知他所属于的部门，从部门的拥有人员的记录中去除掉这我的员。

（4）人员调职，一样须要通知相关的部门，先从原来的部门中去除掉，而后再到新的部门中添加上。

看了上述的描述，感受如何？

　　麻烦的根源在什么地方呢？仔细想一想，对了，麻烦的根源就在于部门和人员之间的耦合，这样致使操做人员的时候，须要操做全部相关的部门，而操做部门的时候又须要操做全部相关的人员，使得部门和人员搅和在了一块儿。

3：中介者来解决​

　　找到了根源就好办了，采用中介者模式，引入一个中介者对象来管理部门和人员之间的关系，就能解决这些问题了。​ 若是采用标准的中介者模式，想一想上面提出的那些问题点吧，就知道实现起来会很别扭。所以采用广义的中介者来解决，这样部门和人员就彻底解耦了，也就是说部门不知道人员，人员也不知道部门，它们彻底分开，它们之间的关系就彻底由中介者对象来管理了。

 

 

中介者模式的优缺点

1：松散耦合

​ 适当地使用中介者模式能够避免同事类之间的过分耦合，使得各同事类之间能够相对独立地使用。

2：集中控制交互

​ 使用中介者模式能够将对象的行为和协做进行抽象，可以比较灵活的处理对象间的相互做用。

3：多对多变成一对多

​ 使用中介者模式能够将对象间一对多的关联转变为一对一的关联，使对象间的关系易于理解和维护。

4：过分集中化

思考中介者模式

中介者模式的本质是：封装交互

什么时候选用中介者模式

1：若是一组对象之间的通讯方式比较复杂，致使相互依赖、结构混乱，能够采用中介者模式，把这些对象相互的交互管理起来，各个对象都只须要和中介者交互，从而使得各个对象松散耦合，结构也更清晰易懂

2：若是一个对象引用不少的对象，并直接跟这些对象交互，致使难以复用该对象。能够采用中介者模式，把这个对象跟其它对象的交互封装到中介者对象里面，这个对象就只须要和中介者对象交互就能够了

​ 　　在面向对象编程中，一个类必然会与其余的类发生依赖关系，彻底独立的类是没有意义的。一个类同时依赖多个类的状况也至关广泛，既然存在这样的状况，说明，一对多的依赖关系有它的合理性，适当的使用中介者模式可使本来凌乱的对象关系清晰，可是若是滥用，则可能会带来反的效果。通常来讲，只有对于那种同事类之间是网状结构的关系，才会考虑使用中介者模式。能够将网状结构变为星状结构，使同事类之间的关系变的清晰一些。

​ 　　中介者模式是一种比较经常使用的模式，也是一种比较容易被滥用的模式。对于大多数的状况，同事类之间的关系不会复杂到混乱不堪的网状结构，所以，大多数状况下，将对象间的依赖关系封装的同事类内部就能够的，没有必要非引入中介者模式。滥用中介者模式，只会让事情变的更复杂。

 代码地址： https://gitee.com/weixiaotao1992/DesignPatternsForJava