设计模式解密(15)- 中介者模式(调停者模式)
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:原文地址 http://www.cnblogs.com/JsonShare/p/7263876.html