在我们实际业务中,可能存在多个类之间相互调用,形成了一个复杂的网状结构。这时候就需要有一种模式去“捋顺”他们之间的关系,引出一个中间者让类之间不再相互调用,该模式就是我们今天的主人公——中介者模式。
一、概念理解
我们先看中介者模式的官方概念:用一个中介者对象来封装一系列的对象交互,中介者使各对象不需要显示地相互引用,从而使其松散耦合,而且可以独立地改变它们之间的交互。
大白话解释就是,引入一个“中介”,用于协调各个对象的关系,各个对象之间不用那么直白的直接调,对象只需要调用中介的方法,中介内部进行逻辑判断,由中介去调用各个对象的方法。
概念基本清楚以后接着看中介者模式包含的角色都有哪些:
中介者角色、各个对象角色是必须的,在面向接口编程原则下,中介者和对象应该抽离出来接口,于是在中介者模式的结构中就包括四种角色(各个对象角色称为同事):
1.中介者(Mediator):中介者是一个接口,该接口定义了用于同事(Colleague)对象之间进行通信的方法;
2.具体中介者(ConcreteMediator):具体中介者是实现中介者接口的类。具体中介者需要包含所有具体同事(ConcreteColleague)的引用,并通过实现中介者接口中的方法来满足具体同事之间的通信要求;
3.同事(Colleague):一个接口,规定了具体同事需要实现的方法;
4.具体同事(ConcreteColleague):实现了同事接口的类。具体同事需要包含具体中介者的引用,一个具体同事需要和其他具体同事交互时,只需将自己的请求通知给它所包含的具体中介者的引用。
如果在一个业务场景中,一个公司有很多同事,同事1 管理的有自己的数据,有时候也会调用同事2的数据。
在中介者模式下,同事1和同事2 之间不再相互调用,由中介者统一调用,同事类中要持有中介者对象,中介者方法中要有判断属于哪个角色的方法。
基于四个角色,实现初试的demo。
读者可以拉取完整代码到本地进行学习,实现代码均测试通过后上传到码云。
本地源码下载
二、案例实现
抽象同事类:
抽象同事中要持有中介者的引用
/** * 抽象同事类 * @author tcy * @Date 14-09-2022 */ public abstract class Colleague { //抽象中介者引用 protected Mediator mediator; public Colleague(Mediator mediator) { this.mediator = mediator; } //数据更新方法 public abstract void update(); //数据更改方法 public abstract void changed(); }
具体同事类1、2:
具体同事类除了有自己的业务逻辑之外,应该还有额外调用中介者的方法
/** * 具体同事2 * @author tcy * @Date 14-09-2022 */ public class ConcreteColleague2 extends Colleague { public ConcreteColleague2(Mediator mediator) { super(mediator); } //自己的方法 @Override public void update() { System.out.println("更新同事类2"); } //调用同事的方法 @Override public void changed() { System.out.println("同事类2数据更改"); mediator.operation(this); } } /** * 具体同事1 * @author tcy * @Date 14-09-2022 */ public class ConcreteColleague1 extends Colleague{ public ConcreteColleague1(Mediator mediator) { super(mediator); } @Override public void update() { System.out.println("更新同事类1"); } @Override public void changed() { System.out.println("同事类1数据更改"); mediator.operation(this); } }
抽象中介者:
抽象中介者应该是持有所有同事对象,并且应该有一个方法去调用别的同事
/** * 抽象中介者 */ public abstract class Mediator { protected ArrayList<Colleague> colleagues = new ArrayList<>(); public void add(Colleague colleague) { colleagues.add(colleague); } public abstract void operation(Colleague colleague); }
具体中介者:
具体中介者实现抽象中介者的方法,根据条件调用不同的同事
/** * 具体中介者 * @author tcy * @Date 14-09-2022 */ public class ConcreteMediator extends Mediator { @Override public void operation(Colleague colleague) { if(colleague instanceof ConcreteColleague1) colleagues.get(1).update(); else if(colleague instanceof ConcreteColleague2) colleagues.get(0).update(); } }
三、中介者模式源码中的应用
中介者模式的典型应用就是Jdk中的Timer 类。
我们知道Timer 类的主要作用是用于定时任务,定时任务之间会存在通信问题,如果众多的定时任务都相互通信,那对于系统对象间的引用来说就是一灾难,引出中介者模式就是理所应当的了。
当有新的任务加入到队列中,均把该任务当做同事,各个任务之间的通信都是由Timer 类来完成,Timer 类就相当于中介者的角色。
我们知道,Timer 类实现定时任务的主要方法就是schedule(),schedule()有一堆的重载方法。
我们点开任意的schedule方法。
public void schedule(TimerTask task, Date firstTime, long period) { if (period <= 0) throw new IllegalArgumentException("Non-positive period."); sched(task, firstTime.getTime(), -period); }
均调用了sched()私有方法。
我们重点看红线标记的代码块,将任务放入一个 队列中,这个队列和我们例子中的Arrlist是一个作用。
private final TaskQueue queue = new TaskQueue();
判断以后,调用Object的notify()方法,进行线程间的通信。
试想一下,如果没有这个中介,每个定时任务都手动的调用notify()方法,该有多么痛苦。
四、总结
网上讲解设计模式的文章很多,能把中介模式讲清楚很简单,但能说明白何时使用合适的设计模式却是难上加难。在前三章设计模式的基础之上,第四章总结看完,希望读者能对正确使用设计模式有一个清晰的轮廓。
很多网上的博客都说要职责清晰才可使用中介者模式,如果类的职责是混乱的,那中介者的逻辑写起来就很难受。还有多个对象间耦合严重,类图之间出现了网状结构,这时候就可以考虑中介者模式了,如果仅仅是为了使用中介者模式而使用,那就得不偿失了。
中介者的优点突出,中介者模式的出现会让网状结构,有序的转化为星状结构。能有序降低类的复杂度,将多对多的关系转化为一对多,降低了类之间的耦合。
缺点也很明显,会增加类的个数,同事类越多,中介者的逻辑也就越复杂。
以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,谢谢大家对自由互联的支持。如果你想了解更多相关内容请查看下面相关链接