详解Java设计模式编程中的中介者模式
作者:卡奴达摩 发布时间:2021-09-24 02:48:54
定义:用一个中介者对象封装一系列的对象交互,中介者使各对象不需要显示地相互作用,从而使耦合松散,而且可以独立地改变它们之间的交互。
类型:行为类模式
类图:
中介者模式的结构
中介者模式又称为调停者模式,从类图中看,共分为3部分:
抽象中介者:定义好同事类对象到中介者对象的接口,用于各个同事类之间的通信。一般包括一个或几个抽象的事件方法,并由子类去实现。
中介者实现类:从抽象中介者继承而来,实现抽象中介者中定义的事件方法。从一个同事类接收消息,然后通过消息影响其他同时类。
同事类:如果一个对象会影响其他的对象,同时也会被其他对象影响,那么这两个对象称为同事类。在类图中,同事类只有一个,这其实是现实的省略,在实际应用中,同事类一般由多个组成,他们之间相互影响,相互依赖。同事类越多,关系越复杂。并且,同事类也可以表现为继承了同一个抽象类的一组实现组成。在中介者模式中,同事类之间必须通过中介者才能进行消息传递。
为什么要使用中介者模式
一般来说,同事类之间的关系是比较复杂的,多个同事类之间互相关联时,他们之间的关系会呈现为复杂的网状结构,这是一种过度耦合的架构,即不利于类的复用,也不稳定。例如在下图中,有六个同事类对象,假如对象1发生变化,那么将会有4个对象受到影响。如果对象2发生变化,那么将会有5个对象受到影响。也就是说,同事类之间直接关联的设计是不好的。
如果引入中介者模式,那么同事类之间的关系将变为星型结构,从图中可以看到,任何一个类的变动,只会影响的类本身,以及中介者,这样就减小了系统的耦合。一个好的设计,必定不会把所有的对象关系处理逻辑封装在本类中,而是使用一个专门的类来管理那些不属于自己的行为。
例
下面给出具体的代码例子,对比通用类图增加了AbstractColleague抽象同事类和AbstractMediator抽象中介者,另外就是两个具体同事类和一个具体中介者,代码中有较多注释,相应类图也不给出了,应该不难理解的:
同事类族:
//抽象同事类
abstract class AbstractColleague {
protected AbstractMediator mediator;
/**既然有中介者,那么每个具体同事必然要与中介者有联系,
* 否则就没必要存在于 这个系统当中,这里的构造函数相当
* 于向该系统中注册一个中介者,以取得联系
*/
public AbstractColleague(AbstractMediator mediator) {
this.mediator = mediator;
}
// 在抽象同事类中添加用于与中介者取得联系(即注册)的方法
public void setMediator(AbstractMediator mediator) {
this.mediator = mediator;
}
}
//具体同事A
class ColleagueA extends AbstractColleague {
//每个具体同事都通过父类构造函数与中介者取得联系
public ColleagueA(AbstractMediator mediator) {
super(mediator);
}
//每个具体同事必然有自己分内的事,没必要与外界相关联
public void self() {
System.out.println("同事A --> 做好自己分内的事情 ...");
}
//每个具体同事总有需要与外界交互的操作,通过中介者来处理这些逻辑并安排工作
public void out() {
System.out.println("同事A --> 请求同事B做好分内工作 ...");
super.mediator.execute("ColleagueB", "self");
}
}
//具体同事B
class ColleagueB extends AbstractColleague {
public ColleagueB(AbstractMediator mediator) {
super(mediator);
}
public void self() {
System.out.println("同事B --> 做好自己分内的事情 ...");
}
public void out() {
System.out.println("同事B --> 请求同事A做好分内工作 ...");
super.mediator.execute("ColleagueA", "self");
}
}
中介者类族:
//抽象中介者
abstract class AbstractMediator {
//中介者肯定需要保持有若干同事的联系方式
protected Hashtable<String, AbstractColleague> colleagues = new Hashtable<String, AbstractColleague>();
//中介者可以动态地与某个同事建立联系
public void addColleague(String name, AbstractColleague c) {
this.colleagues.put(name, c);
}
//中介者也可以动态地撤销与某个同事的联系
public void deleteColleague(String name) {
this.colleagues.remove(name);
}
//中介者必须具备在同事之间处理逻辑、分配任务、促进交流的操作
public abstract void execute(String name, String method);
}
//具体中介者
class Mediator extends AbstractMediator{
//中介者最重要的功能,来回奔波与各个同事之间
public void execute(String name, String method) {
if("self".equals(method)){ //各自做好分内事
if("ColleagueA".equals(name)) {
ColleagueA colleague = (ColleagueA)super.colleagues.get("ColleagueA");
colleague.self();
}else {
ColleagueB colleague = (ColleagueB)super.colleagues.get("ColleagueB");
colleague.self();
}
}else { //与其他同事合作
if("ColleagueA".equals(name)) {
ColleagueA colleague = (ColleagueA)super.colleagues.get("ColleagueA");
colleague.out();
}else {
ColleagueB colleague = (ColleagueB)super.colleagues.get("ColleagueB");
colleague.out();
}
}
}
}
测试类:
//测试类
public class Client {
public static void main(String[] args) {
//创建一个中介者
AbstractMediator mediator = new Mediator();
//创建两个同事
ColleagueA colleagueA = new ColleagueA(mediator);
ColleagueB colleagueB = new ColleagueB(mediator);
//中介者分别与每个同事建立联系
mediator.addColleague("ColleagueA", colleagueA);
mediator.addColleague("ColleagueB", colleagueB);
//同事们开始工作
colleagueA.self();
colleagueA.out();
System.out.println("======================合作愉快,任务完成!\n");
colleagueB.self();
colleagueB.out();
System.out.println("======================合作愉快,任务完成!");
}
}
测试结果:
同事A --> 做好自己分内的事情 ...
同事A --> 请求同事B做好分内工作 ...
同事B --> 做好自己分内的事情 ...
======================合作愉快,任务完成!
同事B --> 做好自己分内的事情 ...
同事B --> 请求同事A做好分内工作 ...
同事A --> 做好自己分内的事情 ...
======================合作愉快,任务完成!
虽然以上代码中只有两个具体同事类,并且测试类中也只是创建了两个同事,但是这些我们都可以根据中介者模式的宗旨进行适当地扩展,即增加具体同事类,然后中介者就得担负更加重的任务了。为啥?我们看到上面具体中介者类Mediator中的execute()方法中现在就有一堆冗长的判断代码了。虽然可以把它分解并增加到Mediator类中的其它private方法中,但是具体的业务逻辑是少不了的。
所以,在解耦同事类之间的联系的同时,中介者自身也不免任务过重,因为几乎所有的业务逻辑都交代到中介者身上了,可谓是“万众期待”的一个角色了。这就是中介者模式的不足之处了 。
此外,上面这个代码例子是相当理想的了,有时候我们根本抽取不了“同事”之间的共性来形成一个AbstractColleague抽象同事类,这也大大增加了中介者模式的使用难度。
修改:
由于上面代码实现中存在 benjielin 前辈提出的“双向关联暴露在App中”的不足之处,根据给出的改进方法2,修改上面代码,如下:
修改后的同事类族:
//抽象同事类
abstract class AbstractColleague {
protected AbstractMediator mediator;
//舍去在构造函数中建立起与中介者的联系
// public AbstractColleague(AbstractMediator mediator) {
// this.mediator = mediator;
// }
// 在抽象同事类中添加用于与中介者取得联系(即注册)的方法
public void setMediator(AbstractMediator mediator) {
this.mediator = mediator;
}
}
//具体同事A
class ColleagueA extends AbstractColleague {
//舍去在构造函数中建立起与中介者的联系
// public ColleagueA(AbstractMediator mediator) {
// super(mediator);
// }
//每个具体同事必然有自己分内的事,没必要与外界相关联
public void self() {
System.out.println("同事A --> 做好自己分内的事情 ...");
}
//每个具体同事总有需要与外界交互的操作,通过中介者来处理这些逻辑并安排工作
public void out() {
System.out.println("同事A --> 请求同事B做好分内工作 ...");
super.mediator.execute("ColleagueB", "self");
}
}
//具体同事B
class ColleagueB extends AbstractColleague {
//舍去在构造函数中建立起与中介者的联系
// public ColleagueB(AbstractMediator mediator) {
// super(mediator);
// }
public void self() {
System.out.println("同事B --> 做好自己分内的事情 ...");
}
public void out() {
System.out.println("同事B --> 请求同事A做好分内工作 ...");
super.mediator.execute("ColleagueA", "self");
}
}
修改后的中介者:
//抽象中介者
abstract class AbstractMediator {
//中介者肯定需要保持有若干同事的联系方式
protected Hashtable<String, AbstractColleague> colleagues = new Hashtable<String, AbstractColleague>();
//中介者可以动态地与某个同事建立联系
public void addColleague(String name, AbstractColleague c) {
// 在中介者这里帮助具体同事建立起于中介者的联系
c.setMediator(this);
this.colleagues.put(name, c);
}
//中介者也可以动态地撤销与某个同事的联系
public void deleteColleague(String name) {
this.colleagues.remove(name);
}
//中介者必须具备在同事之间处理逻辑、分配任务、促进交流的操作
public abstract void execute(String name, String method);
}
//测试类
public class Client {
public static void main(String[] args) {
//创建一个中介者
AbstractMediator mediator = new Mediator();
//不用构造函数为具体同事注册中介者来取得联系了
// ColleagueA colleagueA = new ColleagueA(mediator);
// ColleagueB colleagueB = new ColleagueB(mediator);
ColleagueA colleagueA = new ColleagueA();
ColleagueB colleagueB = new ColleagueB();
//中介者分别与每个同事建立联系
mediator.addColleague("ColleagueA", colleagueA);
mediator.addColleague("ColleagueB", colleagueB);
//同事们开始工作
colleagueA.self();
colleagueA.out();
System.out.println("======================合作愉快,任务完成!\n");
colleagueB.self();
colleagueB.out();
System.out.println("======================合作愉快,任务完成!");
}
}
测试之后的结果与修改前一样。


猜你喜欢
- UGUI的滑动组件虽然表现上和NGUI的ScrollView一致,但是它更美好的是开放源码的,不了解原理的时候直接查源码就OK。在使用Scr
- 一、前言近期一项目A需实现数据同步到另一项目B数据库中,在不改变B项目的情况下,只好选择项目A中切换数据源,直接把数据写入项目B的数据库中。
- 本文实例为大家分享了基于C#实现网页爬虫的详细代码,供大家参考,具体内容如下HTTP请求工具类:功能:1、获取网页html2、下载网络图片u
- Java的三种标准注解和四种元注解先来说说什么是注解注解(也被称为元数据)为我们在代码中添加信息提供了一种形式化的方法,使我们可以在稍后某个
- SharedPreferences是Android中存储简单数据的一个工具类。可以想象它是一个小小的Cookie,它通过用键值对的方式把简单
- Java命令运行jar 报错运行jar命令java -jar xxx.jar报错:Caused by: java.lang.ClassNot
- 这篇文章主要介绍了如何使用mybatis-generator自动生成代码,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考
- 目录Demo展示介绍计时器功能Unity计时器Demo展示介绍游戏中有非常多的计时功能,比如:各种cd,以及需要延时调用的方法;一般实现有一
- 一、lateinit延迟初始化关键字Kotlin中很多语法特性,如变量不可变,变量不可为空,等等 这些特性都是为了尽可能地保证程序安全而设计
- Java实现Dijkstra输出指定起点到终点的最短路径前言:最近在公司参加了一个比赛,其中涉及的一个问题,可以简化成如是描述:一个二维矩阵
- 一、开篇通过对之前Java之路的了解之后,相信初学者们都对Java有了一个比较深印象的了解了。但是事情不能总停留在理论层面,还得多多实现,才
- 简介说明 项目我们经常会有前后端时间转换的场景,比如:创建时间、更新时间等。一般情况下
- 寻找到application.yml的读取的操作。从spring.factories 中查看到# Application Listeners
- 一、前言文稿扫描大家用的都比较频繁、想是各种证件、文件都可以通过扫描文稿功能保存到手机。相比直接拍照,在扫描文稿时,程序会对图像进行一些矫正
- 文件上传大小设置#文件大小 MB必须大写# maxFileSize 是单个文件大小# maxRequestSize是
- 前言值类型和引用类型,是c#比较基础,也必须掌握的知识点,但是也不是那么轻易就能掌握,今天跟着老胡一起来看看吧。 典型类型首先我们
- 包的作用,1是为了防止类和方法的重名,2是为了管理众多的java类。步骤 1 工具包里面有很多个工具类之前讲了打印数据的方法:S
- 1,刚刚在别人开源的项目中看到了一个挺不错的用户体验,效果图如下:2,那下面我们就来实现一下,首先看一下布局,由于一般只是我们包含头像的那部
- 1. 概述官方JavaDocsApi:javax.swing.JCheckBoxJCheckBox,复选框。JCheckBox 常用构造方法
- 首先,引入依赖:<dependency> <groupId>org.springframe