Android编程设计模式之中介者模式详解-创新互联

本文实例讲述了Android编程设计模式之中介者模式。分享给大家供大家参考，具体如下：

一、介绍

中介者模式（Mediator Pattern）也称为调解者模式或调停者模式，Mediator本身就有调停者和调解者的意思。

在日常生活中调停者或调解者这个角色我们见得比较多的是“和事老”，也就是说调解两个有争端的人的角色，举个不恰当的例子，比如爸妈吵架，孩子或者双方父母则会出面劝架或阻止争吵，这里孩子或双方父母则是充当的是调解者的模式。

而对于中介呢？大家平时听得最多的莫过于房产中介了，在房地产飞速发展的今天，各种房产中介公司如雨后春笋般冒出来，房产中介承担的责任很简单，就是在买房者与卖房者之间建立一座桥梁沟通两者，比如小民现在手里有套房子需要出售，于是他找房产中介并告诉房产中介房子的期望售价和房子的相关信息，然后房产中介则将这些信息收集汇总有时还会美化一番，然后把广告挂在橱窗里等待买房者，如果有人有意向购买这套房子，比如这里以小辉为例，房产中介就会告诉小辉关于这套房产的相关信息，如房龄、售价等，有时还会带小辉去房子里实际参观一番，最终小辉将自己的意愿告诉房产中介，再由房产中介去与小民进行沟通。也就是说在整个房产协商的过程中，小民和小辉买卖双方是很少直接接触的，大多数情况下都是通过房产中介来传达信息，可能只有在最终进行房产交接时小民和小辉才会正式见面。

这就是我们现实生活中常见的调解者与中介者，但是，这里我们要说的中介者模式比起上述的两个例子来要复杂的多，上面我们所述的例子中，中介者或调解者所要协调的也就两类对象，而我们的中介者模式中需要协调的是多类对象。

这里还是举一个小例子来说明，本书的阅读者大多都是IT从业者，说得更准确些都是做APP的，一般来说，一个做APP的公司可以分为几大模块：运维、产品、开发、设计还有测试，每当一个新APP开始制作或者发布新版本需要制作之前，公司会开一个研讨会，运维负责市场了解用户使用倾向，研发的会说用户反映界面不好看要求修改界面……这样大家你一句我一句的讨论一半天也没有啥实质性结果，主要原因在于大家都站在自己的立场考虑问题，这样的团队研讨会即使再开下去也没什么意义，这时候如果有一个人不属于运维、产品、开发、设计任一方的人站出来说，大家把各自的意见都跟我说，由我来权衡并作出最终的决定，不管决定如何你们都要照做。因为这个人不代表任何一方，于是大家都全票表示肯定，这么一来一个方案很快就定下来，而这个作出最终决定的人我们就称之为中介者，这里的中介者与我们的中介者模式一样面对的是多类对象，这里其实大家可以看到中介者模式的一些特性，每一个中介者都会知道所有的同事，比如上面我们所说的运维、产品、开发、设计还有测试，但是这些同事呢可以互不相识，而中介者不属于同事的任何一方，也不偏袒任何一方，这么一说相信大家对中介者模式会有一个非常清晰的了解。

二、定义

中介者模式包装了一系列对象互相作用的方式，使得这些对象不必相互明显作用。从而使它们可以松散偶合。当某些对象之间的作用发生改变时，不会立即影响其他的一些对象之间的作用。保证这些作用可以彼此独立的变化。中介者模式将多对多的相互作用转化为一对多的相互作用。中介者模式将对象的行为和协作抽象化，把对象在小尺度的行为上与其他对象的相互作用分开处理。

三、使用场景

当对象之间的交互操作很多且每个对象的行为操作都依赖彼此时，为防止在修改一个对象的行为时，同时涉及修改很多其他对象的行为，可采用中介者模式，来解决紧耦合问题。该模式将对象之间的多对多关系变成一对多关系，中介者对象将系统从网状结构变成以调停者为中心的星形结构，达到降低系统的复杂性，提高可扩展性的作用。

四、中介者模式的UML类图

UML类图：

角色介绍：

Mediator：抽象的中介者角色，定义了同事对象到中介者的接口。

ConcreteMediator：具体的中介者角色，从具体的同事对象接收消息，同时向具体的同事对象发出命令。

Colleague：抽象同事类角色，定义了中介者对象的接口，只知道中介而不知道其他同事对象。

ConcreteColleagueA，ConcreteColleagueB：具体的同事类角色，每个具体同事类都知道本身在小范围内的行为，而不知道他在大范围中的行为。

模板代码：

抽象的中介者：

public interface Mediator {
  void change();
}