1、简介
别名:调停者模式
定义:用一个中介对象来封装一系列的对象交互,中介者使各对象不需要显示地相互引用。从而使其耦合松散,而且可以独立地改变它们之间的交互。
主要解决:对象与对象之间存在大量的关联关系,这样势必会导致系统的结构变得很复杂,同时若一个对象发生改变,我们也需要跟踪与之相关联的对象,同时做出相应的处理。
何时使用:多个类相互耦合,形成了网状结构。
如何解决:将上述网状结构分离为星型结构。
核心思想:1、就是将网状结构处理成星型结构
2、将多对多处理成一对多
本质:封装对象间的交互
英文:Mediator
类型:行为型
PS:附图示解决的问题
2、类图及组成
(引)类图:
组成:
● 抽象中介者(Mediator)角色:定义统一的接口用于各同事角色之间的通信,其中主要方法是一个(或多个)事件方法。
● 具体中介者(ConcreteMediator)角色:实现了抽象中介者所声明的事件方法。具体中介者知晓所有的具体同事类,并负责具体的协调各同事对象的交互关系。
● 抽象同事类(Colleague)角色:定义出中介者到同事角色的接口。同事角色只知道中介者而不知道其余的同事角色。与其他的同事角色通信的时候,一定要通过中介者角色协作。
● 具体同事类(ConcreteColleague)角色:所有的具体同事类均从抽象同事类继承而来。实现自己的业务,在需要与其他同事通信的时候,就与持有的中介者通信,中介者会负责与其他的同事交互。
代码结构:
//抽象中介者类
public interface Mediator {
/**
* 同事对象在自身改变的时候来通知中介者的方法
* 让中介者去负责相应的与其他同事对象的交互
*/
public void changed(Colleague c);
}
//抽象同事类
public abstract class Colleague {
//持有一个中介者对象
private Mediator mediator;
/**
* 构造函数
*/
public Colleague(Mediator mediator){
this.mediator = mediator;
}
/**
* 获取当前同事类对应的中介者对象
*/
public Mediator getMediator() {
return mediator;
}
}
//具体中介者类
public class ConcreteMediator implements Mediator {
//持有并维护同事A
private ConcreteColleagueA colleagueA;
//持有并维护同事B
private ConcreteColleagueB colleagueB;
public void setColleagueA(ConcreteColleagueA colleagueA) {
this.colleagueA = colleagueA;
}
public void setColleagueB(ConcreteColleagueB colleagueB) {
this.colleagueB = colleagueB;
}
@Override
public void changed(Colleague c) {
/**
* 某一个同事类发生了变化,通常需要与其他同事交互
* 具体协调相应的同事对象来实现协作行为
*/
}
}
//具体同事类
public class ConcreteColleagueA extends Colleague {
public ConcreteColleagueA(Mediator mediator) {
super(mediator);
}
/**
* 示意方法,执行某些操作
*/
public void operation(){
//在需要跟其他同事通信的时候,通知中介者对象
getMediator().changed(this);
}
}
public class ConcreteColleagueB extends Colleague {
public ConcreteColleagueB(Mediator mediator) {
super(mediator);
}
/**
* 示意方法,执行某些操作
*/
public void operation(){
//在需要跟其他同事通信的时候,通知中介者对象
getMediator().changed(this);
}
}
3、实例引入
假设现在有A、B、C建立了一个微信讨论组,他们有什么问题就在这里讨论,A在犹豫今天中午吃什么,A同学只要在讨论组里问一声就可以了,不必要直接去和B、C同学打交道,省去了很多麻烦事。怎么实现呢?
抽象中介者:
package com.designpattern.Mediator;
/**
* 抽象中介者类
* @author Json<<json1990@foxmail.com>>
*/
public interface Mediator {
/**
* 发送消息
*/
public void chat(People p,String message);
}
抽象同事类:
package com.designpattern.Mediator;
/**
* 抽象同事类 -- 聊天人员
* @author Json<<json1990@foxmail.com>>
*/
public abstract class People {
//人员昵称
private String name;
//持有一个中介者对象
private Mediator mediator;
/**
* 构造函数
*/
public People(Mediator mediator,String name){
this.mediator = mediator;
this.name = name;
}
/**
* 获取中介者对象
*/
public Mediator getMediator() {
return mediator;
}
/**
* 获取昵称
*/
public String getName() {
return name;
}
/**
* 接收消息
*/
public abstract void receive(String message);
/**
* 发送消息
*/
public abstract void send(String message);
}
3个具体同事类:
package com.designpattern.Mediator;
/**
* 具体同事类 -- 人员a
* @author Json<<json1990@foxmail.com>>
*/
public class PeopleA extends People {
public PeopleA(Mediator mediator,String name) {
super(mediator, name);
}
/**
* 接收消息
*/
public void receive(String message){
System.out.println("【A】收到消息:【"+message+"】");
}
/**
* 发送消息
*/
public void send(String message){
System.out.println("【A】发出消息:【"+message+"】");
}
}
package com.designpattern.Mediator;
/**
* 具体同事类 -- 人员b
* @author Json<<json1990@foxmail.com>>
*/
public class PeopleB extends People {
public PeopleB(Mediator mediator,String name) {
super(mediator, name);
}
/**
* 接收消息
*/
public void receive(String message){
System.out.println("【B】收到消息:【"+message+"】");
}
/**
* 发送消息
*/
public void send(String message){
System.out.println("【B】发出消息:【"+message+"】");
}
}
package com.designpattern.Mediator;
/**
* 具体同事类 -- 人员c
* @author Json<<json1990@foxmail.com>>
*/
public class PeopleC extends People {
public PeopleC(Mediator mediator,String name) {
super(mediator, name);
}
/**
* 接收消息
*/
public void receive(String message){
System.out.println("【C】收到消息:【"+message+"】");
}
/**
* 发送消息
*/
public void send(String message){
System.out.println("【C】发出消息:【"+message+"】");
}
}
具体中介者实现:
package com.designpattern.Mediator;
/**
* 具体中介者类
* @author Json<<json1990@foxmail.com>>
*/
public class MessageMediator implements Mediator {
//持有并维护人员A
private PeopleA A;
//持有并维护人员B
private PeopleB B;
//持有并维护人员C
private PeopleC C;
public void setPeopleA(PeopleA A) {
this.A = A;
}
public void setPeopleB(PeopleB B) {
this.B = B;
}
public void setPeopleC(PeopleC C) {
this.C = C;
}
/**
* 发送消息
*/
@Override
public void chat(People p,String message) {
if (p instanceof PeopleA) {
A.send(message);
B.receive(message);
C.receive(message);
} else if (p instanceof PeopleB) {
B.send(message);
A.receive(message);
C.receive(message);
} else if (p instanceof PeopleC) {
C.send(message);
A.receive(message);
B.receive(message);
}
}
}
测试:
package com.designpattern.Mediator;
/**
* 测试
* @author Json<<json1990@foxmail.com>>
*/
public class Client {
public static void main(String[] args) {
MessageMediator mediator = new MessageMediator();
PeopleA a = new PeopleA(mediator,"A");
PeopleB b = new PeopleB(mediator,"B");
PeopleC c = new PeopleC(mediator,"C");
mediator.setPeopleA(a);
mediator.setPeopleB(b);
mediator.setPeopleC(c);
mediator.chat(a, "中午吃啥饭?");
System.out.println();
mediator.chat(b,"我想吃刀削面");
System.out.println();
mediator.chat(c,"我也想吃刀削面");
System.out.println();
mediator.chat(a, "行,那中午一起去吃刀削面吧");
System.out.println();
}
}
结果:
【A】发出消息:【中午吃啥饭?】
【B】收到消息:【中午吃啥饭?】
【C】收到消息:【中午吃啥饭?】
【B】发出消息:【我想吃刀削面】
【A】收到消息:【我想吃刀削面】
【C】收到消息:【我想吃刀削面】
【C】发出消息:【我也想吃刀削面】
【A】收到消息:【我也想吃刀削面】
【B】收到消息:【我也想吃刀削面】
【A】发出消息:【行,那中午一起去吃刀削面吧】
【B】收到消息:【行,那中午一起去吃刀削面吧】
【C】收到消息:【行,那中午一起去吃刀削面吧】
4、优缺点
优点:
简化了对象之间的交互:它用中介者和同事的一对多交互代替了原来同事之间的多对多交互,一对多关系更容易理解、维护和扩展,将原本难以理解的网状结构转换成相对简单的星型结构。
各同事对象之间解耦:中介者有利于各同事之间的松耦合,我们可以独立的改变和复用每一个同事和中介者,增加新的中介者和新的同事类都比较方便,更好地符合“开闭原则”。
减少子类生成:中介者将原本分布于多个对象间的行为集中在一起,改变这些行为只需生成新的中介者子类即可,这使各个同事类可被重用,无须对同事类进行扩展。
缺点:
中介者会庞大,变得复杂难以维护。
5、使用场景
1、对象间的交互虽定义明确然而非常复杂,导致一组对象彼此相互依赖而且难以理解。
2、因为对象引用了许多其他对象并与其通信,导致对象难以复用。
3、想要定制一个分布在多个类中的逻辑或者行为,又不想生成太多子类。
实际应用:
Mediator模式在事件驱动类应用中比较多,例如聊天、消息传递等等,需要有一个MessageMediator,专门负责request/reponse之间任务的调节。
MVC模式中,Controller是一种Mediator。
JDK的具体应用:
java.util.Timer
java.util.concurrent.Executor#execute()
java.util.concurrent.ExecutorService#submit()
java.lang.reflect.Method#invoke()
.......
6、中介者模式和外观模式
1、外观模式是结构型模式,中介者模式是行为型模式;
2、中介者模式主要用来封装多个平等对象之间相互的交互,多用在系统内部的多个模块之间;
外观模式旨在提供一个高层次的接口,封装的是单向的交互,是从客户端访问系统的调用,没有从系统中来访问客户端的调用;
外观模式协议是单向,中介者模式协议是双向;
3、中介者模式的实现里面,是需要实现具体的交互功能的;而外观模式的实现里面,一般是组合调用或是转调内部实现的功能,通常外观模式不添加额外的功能;
4、中介者模式的目的主要是松散多个模块之间的耦合,把这些耦合关系全部放到中介者中去实现;而外观模式的目的是简化客户端的调用;
7、总结
中介者模式很容易在系统中应用,也很容易在系统中误用。当系统出现了“多对多”交互复杂的对象群,不要急于使用中介者模式,而先要思考在设计上是不是合理↓↓↓
PS:不应当在职责混乱的时候使用;
PS:源码地址 https://github.com/JsonShare/DesignPattern/tree/master
PS:原文地址 https://blog.youkuaiyun.com/Json_wangqiang/article/details/85276194