设计模式笔记--中介者模式
2016-01-12 15:45
423 查看
常用设计模式有23中,分为:
创建型模式(主要用于创建对象)
1、单例模式 2、工厂方法模式
3、抽象工厂模式 4、建造者模式 5、原型模式
行为型模式 (主要用于描述对象或类是怎样交互和怎样分配职责)
1、模板方法模式 2、中介者模式 3、命令模式
4、责任链模式 5、策略模式 6、迭代器模式
7、观察者模式 8、备忘录模式 9、访问者模式 10、状态模式 11、解释器模式
结构型模式(主要用于处理类或对象的组合)
1、代理模式 2、装饰模式
3、适配器模式 4、组合模式 5、外观模式(门面模式) 6、享元模式
7、桥梁模式
中介者模式
中介者模式的定义为 :
用一个中介对象封装一系列的对象交互,中介者使各对象不需要显示地相互作用,从而使其耦合松散,而且可以独立地改变它们之间的交互。
从类图中看,中介者模式由以下几部分组成:
● Mediator 抽象中介者角色
抽象中介者角色定义统一的接口,用于各同事角色之间的通信。
● Concrete Mediator 具体中介者角色
具体中介者角色通过协调各同事角色实现协作行为,因此它必须依赖于各个同事角色。
● Colleague 同事角色
每一个同事角色都知道中介者角色,而且与其他的同事角色通信的时候,一定要通过中介者角色协作。
每个同事类的行为分为两种:
第一种是同事本身的行为,比如改变对象本身的状态,处理自己的行为等,这种行为叫做自发行为(Self-Method),与其他的同事类或中介者没有任何的依赖;
第二种是必须依赖中介者才能完成的行为,叫做依赖方法(Dep-Method)。
其通用源码也比较简单,
先看抽象中介者Mediator类,如代码清单14-12所示。
在Mediator抽象类中我们只定义了同事类的注入,为什么使用同事实现类注入而不使用抽象类注入呢?那是因为同事类虽然有抽象,但是没有每个同事类必须要完成的业务方法,当然如果每个同事类都有相同的方法,比如execute、handler等,那当然注入抽象类,做到依赖倒置。
具体的中介者一般只有一个,即通用中介者,其源代码如代码清单14-13所示。
中介者所具有的方法doSomething1和doSomething2都是比较复杂的业务逻辑,为同事类服务,其实现是依赖各个同事类来完成的。
同事类的基类如代码清单14-14所示。
这个基类也非常简单。一般来说,中介者模式中的抽象都比较简单,是为了建立这个中介而服务的,
具体同事类如代码清单14-15所示。
为什么同事类要使用构造函数注入中介者,而中介者使用getter/setter方式注入同事类呢?这是因为同事类必须有中介者,而中介者却可以只有部分同事类。
实例 进、销、存的货物流通
加入了一个中介者作为三个模块的交流核心,每个模块之间不再相互交流,要交流就通过中介者进行。每个模块只负责自己的业务逻辑,不属于自己的则丢给中介者来处理,简化了各模块之间的耦合关系,
建立了两个抽象类AbstractMediator和AbstractColeague,每个对象只是与中介者Mediator之间产生依赖,与其他对象之间没有直接关系,AbstractMediator的作用是实现中介者的抽象定义,定义了一个抽象方法execute,如代码清单14-5所示
代码清单14-6 具体中介者
中介者Mediator定义了多个private方法,其目的是处理各个对象之间的依赖关系,就是说把原有一个对象要依赖多个对象的情况移到中介者的private方法中实现。
由于要使用中介者,我们增加了一个抽象同事类,三个具体的实现类分别继承该抽象类,如代码清单14-7所示。
采购Purchase类如代码清单14-8所示。
上述Purchase类处理自己的职责,与外界有关系的事件处理则交给了中介者来完成。
再来看Stock类,如代码清单14-9所示。
销售管理Sale类如代码清单14-10所示。
场景类 ,如代码清单14-11所示。
在场景类中增加了一个中介者,然后分别传递到三个同事类中,三个类都具有相同的特性:只负责处理自己的活动(行为),与自己无关的活动就丢给中介者处理,程序运行的结果是相同的。
从项目设计上来看,加入了中介者,设计结构清晰了很多,而且类间的耦合性大大减少,代码质量也有了很大的提升。
在多个对象依赖的情况下,通过加入中介者角色,取消了多个对象的关联或依赖关系,减少了对象的耦合性。
优点
中介者模式的优点就是减少类间的依赖,把原有的一对多的依赖变成了一对一的依赖,同事类只依赖中介者,减少了依赖,当然同时也降低了类间的耦合。
缺点
中介者模式的缺点就是中介者会膨胀得很大,而且逻辑复杂,原本N个对象直接的相互依赖关系转换为中介者和同事类的依赖关系,同事类越多,中介者的逻辑就越复杂。
使用场景
中介者模式适用于多个对象之间紧密耦合的情况,紧密耦合的标准是:在类图中出现了蜘蛛网状结构。在这种情况下一定要考虑使用中介者模式,这有利于把蜘蛛网梳理为星型结构,使原本复杂混乱的关系变得清晰简单。
比如原本就简单的几个对象依赖关系,如果为了使用模式而加入了中介者,必然导致中介者的逻辑复杂化,因此中介者模式的使用需要“量力而行”!
大家可以在如下的情况下尝试使用中介者模式:
● N个对象之间产生了相互的依赖关系(N>2)。
● 多个对象有依赖关系,但是依赖的行为尚不确定或者有发生改变的可能,在这种情况下一般建议采用中介者模式,降低变更引起的风险扩散。
● 产品开发。一个明显的例子就是MVC框架,把中介者模式应用到产品中,可以提升产品的性能和扩展性,但是对于项目开发就未必,因为项目是以交付投产为目标,而产品则是以稳定、高效、扩展为宗旨。
一个中介者抽象类一般只有一个实现者,除非中介者逻辑非常复杂,代码量非常大,这时才会出现多个中介者的情况。所以,对于中介者来说,抽象已经没有太多的必要。
创建型模式(主要用于创建对象)
1、单例模式 2、工厂方法模式
3、抽象工厂模式 4、建造者模式 5、原型模式
行为型模式 (主要用于描述对象或类是怎样交互和怎样分配职责)
1、模板方法模式 2、中介者模式 3、命令模式
4、责任链模式 5、策略模式 6、迭代器模式
7、观察者模式 8、备忘录模式 9、访问者模式 10、状态模式 11、解释器模式
结构型模式(主要用于处理类或对象的组合)
1、代理模式 2、装饰模式
3、适配器模式 4、组合模式 5、外观模式(门面模式) 6、享元模式
7、桥梁模式
中介者模式
中介者模式的定义为 :
用一个中介对象封装一系列的对象交互,中介者使各对象不需要显示地相互作用,从而使其耦合松散,而且可以独立地改变它们之间的交互。
从类图中看,中介者模式由以下几部分组成:
● Mediator 抽象中介者角色
抽象中介者角色定义统一的接口,用于各同事角色之间的通信。
● Concrete Mediator 具体中介者角色
具体中介者角色通过协调各同事角色实现协作行为,因此它必须依赖于各个同事角色。
● Colleague 同事角色
每一个同事角色都知道中介者角色,而且与其他的同事角色通信的时候,一定要通过中介者角色协作。
每个同事类的行为分为两种:
第一种是同事本身的行为,比如改变对象本身的状态,处理自己的行为等,这种行为叫做自发行为(Self-Method),与其他的同事类或中介者没有任何的依赖;
第二种是必须依赖中介者才能完成的行为,叫做依赖方法(Dep-Method)。
其通用源码也比较简单,
先看抽象中介者Mediator类,如代码清单14-12所示。
<span style="font-size:18px;">代码清单14-12 通用抽象中介者 public abstract class Mediator { //定义同事类 protected ConcreteColleague1 c1; protected ConcreteColleague2 c2; //通过getter/setter方法把同事类注入进来 public ConcreteColleague1 getC1() { return c1; } public void setC1(ConcreteColleague1 c1) { this.c1 = c1; } public ConcreteColleague2 getC2() { return c2; } public void setC2(ConcreteColleague2 c2) { this.c2 = c2; } //中介者模式的业务逻辑 public abstract void doSomething1(); public abstract void doSomething2(); }</span>
在Mediator抽象类中我们只定义了同事类的注入,为什么使用同事实现类注入而不使用抽象类注入呢?那是因为同事类虽然有抽象,但是没有每个同事类必须要完成的业务方法,当然如果每个同事类都有相同的方法,比如execute、handler等,那当然注入抽象类,做到依赖倒置。
具体的中介者一般只有一个,即通用中介者,其源代码如代码清单14-13所示。
<span style="font-size:18px;">代码清单14-13 通用中介者 public class ConcreteMediator extends Mediator { @Override public void doSomething1() { //调用同事类的方法,只要是public方法都可以调用 super.c1.selfMethod1(); super.c2.selfMethod2(); } public void doSomething2() { super.c1.selfMethod1(); super.c2.selfMethod2(); } } </span>
中介者所具有的方法doSomething1和doSomething2都是比较复杂的业务逻辑,为同事类服务,其实现是依赖各个同事类来完成的。
同事类的基类如代码清单14-14所示。
<span style="font-size:18px;">代码清单14-14 抽象同事类 public abstract class Colleague { protected Mediator mediator; public Colleague(Mediator _mediator){ this.mediator = _mediator; } }</span>
这个基类也非常简单。一般来说,中介者模式中的抽象都比较简单,是为了建立这个中介而服务的,
具体同事类如代码清单14-15所示。
<span style="font-size:18px;">代码清单14-15 具体同事类 public class ConcreteColleague1 extends Colleague { //通过构造函数传递中介者 public ConcreteColleague1(Mediator _mediator){ super(_mediator); } //自有方法 self-method public void selfMethod1(){ //处理自己的业务逻辑 } //依赖方法 dep-method public void depMethod1(){ //处理自己的业务逻辑 //自己不能处理的业务逻辑,委托给中介者处理 super.mediator.doSomething1(); } } </span>
<span style="font-size:18px;">public class ConcreteColleague2 extends Colleague { //通过构造函数传递中介者 public ConcreteColleague2(Mediator _mediator){ super(_mediator); } //自有方法 self-method public void selfMethod2(){ //处理自己的业务逻辑 } //依赖方法 dep-method public void depMethod2(){ //处理自己的业务逻辑 //自己不能处理的业务逻辑,委托给中介者处理 super.mediator.doSomething2(); } }</span>
为什么同事类要使用构造函数注入中介者,而中介者使用getter/setter方式注入同事类呢?这是因为同事类必须有中介者,而中介者却可以只有部分同事类。
实例 进、销、存的货物流通
加入了一个中介者作为三个模块的交流核心,每个模块之间不再相互交流,要交流就通过中介者进行。每个模块只负责自己的业务逻辑,不属于自己的则丢给中介者来处理,简化了各模块之间的耦合关系,
建立了两个抽象类AbstractMediator和AbstractColeague,每个对象只是与中介者Mediator之间产生依赖,与其他对象之间没有直接关系,AbstractMediator的作用是实现中介者的抽象定义,定义了一个抽象方法execute,如代码清单14-5所示
<span style="font-size:18px;">public abstract class AbstractMediator { protected Purchase purchase; protected Sale sale; protected Stock stock; //构造函数 public AbstractMediator(){ purchase = new Purchase(this); sale = new Sale(this); stock = new Stock(this); } //中介者最重要的方法叫做事件方法,处理多个对象之间的关系 public abstract void execute(String str,Object...objects); }</span>
代码清单14-6 具体中介者
<span style="font-size:18px;">public class Mediator extends AbstractMediator { //中介者最重要的方法 public void execute(String str,Object...objects){ if(str.equals("purchase.buy")){ //采购电脑 this.buyComputer((Integer)objects[0]); }else if(str.equals("sale.sell")){ //销售电脑 this.sellComputer((Integer)objects[0]); }else if(str.equals("sale.offsell")){ //折价销售 this.offSell(); }else if(str.equals("stock.clear")){ //清仓处理 this.clearStock(); } } //采购电脑 private void buyComputer(int number){ int saleStatus = super.sale.getSaleStatus(); if(saleStatus>80){ //销售情况良好 System.out.println("采购IBM电脑:"+number + "台"); super.stock.increase(number); }else{ //销售情况不好 int buyNumber = number/2; //折半采购 System.out.println("采购IBM电脑:"+buyNumber+ "台"); } } //销售电脑 private void sellComputer(int number){ if(super.stock.getStockNumber()<number){ //库存数量不够销售 super.purchase.buyIBMcomputer(number); } super.stock.decrease(number); } //折价销售电脑 private void offSell(){ System.out.println("折价销售IBM电脑"+stock.getStockNumber()+"台"); } //清仓处理 private void clearStock(){ //要求清仓销售 super.sale.offSale(); //要求采购人员不要采购 super.purchase.refuseBuyIBM(); } }</span>
中介者Mediator定义了多个private方法,其目的是处理各个对象之间的依赖关系,就是说把原有一个对象要依赖多个对象的情况移到中介者的private方法中实现。
由于要使用中介者,我们增加了一个抽象同事类,三个具体的实现类分别继承该抽象类,如代码清单14-7所示。
<span style="font-size:18px;">public abstract class AbstractColleague { protected AbstractMediator mediator; public AbstractColleague(AbstractMediator _mediator){ this.mediator = _mediator; } }</span>
采购Purchase类如代码清单14-8所示。
<span style="font-size:18px;">public class Purchase extends AbstractColleague{ public Purchase(AbstractMediator _mediator){ super(_mediator); } //采购IBM电脑 public void buyIBMcomputer(int number){ super.mediator.execute("purchase.buy", number); } //不再采购IBM电脑 public void refuseBuyIBM(){ System.out.println("不再采购IBM电脑"); } }</span>
上述Purchase类处理自己的职责,与外界有关系的事件处理则交给了中介者来完成。
再来看Stock类,如代码清单14-9所示。
<span style="font-size:18px;">代码清单14-9 修改后的库存管理 public class Stock extends AbstractColleague { public Stock(AbstractMediator _mediator){ super(_mediator); } //刚开始有100台电脑 private static int COMPUTER_NUMBER =100; //库存增加 public void increase(int number){ COMPUTER_NUMBER = COMPUTER_NUMBER + number; System.out.println("库存数量为:"+COMPUTER_NUMBER); } //库存降低 public void decrease(int number){ COMPUTER_NUMBER = COMPUTER_NUMBER - number; System.out.println("库存数量为:"+COMPUTER_NUMBER); } //获得库存数量 public int getStockNumber(){ return COMPUTER_NUMBER; } //存货压力大了,就要通知采购人员不要采购,销售人员要尽快销售 public void clearStock(){ System.out.println("清理存货数量为:"+COMPUTER_NUMBER); super.mediator.execute("stock.clear"); } }</span>
销售管理Sale类如代码清单14-10所示。
<span style="font-size:18px;">代码清单14-10 修改后的销售管理 public class Sale extends AbstractColleague { public Sale(AbstractMediator _mediator){ super(_mediator); } //销售IBM电脑 public void sellIBMComputer(int number){ super.mediator.execute("sale.sell", number); System.out.println("销售IBM电脑"+number+"台"); } //反馈销售情况,0~100变化,0代表根本就没人买,100代表非常畅销,出一个卖一个 public int getSaleStatus(){ Random rand = new Random(System.currentTimeMillis()); int saleStatus = rand.nextInt(100); System.out.println("IBM电脑的销售情况为:"+saleStatus); return saleStatus; } //折价处理 public void offSale(){ super.mediator.execute("sale.offsell"); } }</span>
场景类 ,如代码清单14-11所示。
<span style="font-size:18px;">代码清单14-11 修改后的场景类 public class Client { public static void main(String[] args) { AbstractMediator mediator = new Mediator(); //采购人员采购电脑 System.out.println("------采购人员采购电脑--------"); Purchase purchase = new Purchase(mediator); purchase.buyIBMcomputer(100); //销售人员销售电脑 System.out.println("\n------销售人员销售电脑--------"); Sale sale = new Sale(mediator); sale.sellIBMComputer(1); //库房管理人员管理库存 System.out.println("\n------库房管理人员清库处理--------"); Stock stock = new Stock(mediator); stock.clearStock(); } }</span>
在场景类中增加了一个中介者,然后分别传递到三个同事类中,三个类都具有相同的特性:只负责处理自己的活动(行为),与自己无关的活动就丢给中介者处理,程序运行的结果是相同的。
从项目设计上来看,加入了中介者,设计结构清晰了很多,而且类间的耦合性大大减少,代码质量也有了很大的提升。
在多个对象依赖的情况下,通过加入中介者角色,取消了多个对象的关联或依赖关系,减少了对象的耦合性。
优点
中介者模式的优点就是减少类间的依赖,把原有的一对多的依赖变成了一对一的依赖,同事类只依赖中介者,减少了依赖,当然同时也降低了类间的耦合。
缺点
中介者模式的缺点就是中介者会膨胀得很大,而且逻辑复杂,原本N个对象直接的相互依赖关系转换为中介者和同事类的依赖关系,同事类越多,中介者的逻辑就越复杂。
使用场景
中介者模式适用于多个对象之间紧密耦合的情况,紧密耦合的标准是:在类图中出现了蜘蛛网状结构。在这种情况下一定要考虑使用中介者模式,这有利于把蜘蛛网梳理为星型结构,使原本复杂混乱的关系变得清晰简单。
比如原本就简单的几个对象依赖关系,如果为了使用模式而加入了中介者,必然导致中介者的逻辑复杂化,因此中介者模式的使用需要“量力而行”!
大家可以在如下的情况下尝试使用中介者模式:
● N个对象之间产生了相互的依赖关系(N>2)。
● 多个对象有依赖关系,但是依赖的行为尚不确定或者有发生改变的可能,在这种情况下一般建议采用中介者模式,降低变更引起的风险扩散。
● 产品开发。一个明显的例子就是MVC框架,把中介者模式应用到产品中,可以提升产品的性能和扩展性,但是对于项目开发就未必,因为项目是以交付投产为目标,而产品则是以稳定、高效、扩展为宗旨。
一个中介者抽象类一般只有一个实现者,除非中介者逻辑非常复杂,代码量非常大,这时才会出现多个中介者的情况。所以,对于中介者来说,抽象已经没有太多的必要。
相关文章推荐
- objectARX获取当前图层所有文字样式
- linux 防火墙--firewalld学习
- javascript作用域链与闭包
- 返回顶部按钮
- 算法分析的数学基础
- 常用正则表达式
- 显式调用析构函数与栈中 new 对象
- AT&T ASM
- Windows上安装py-leveldb
- 使用GPUImage渲染图片教程
- arduino教程【实战篇】
- 灰度直方图
- 数据结构之队列
- Excel基础
- 百度坐标(bd0911)互转火星坐标(gcj02)和国测局坐标(GPS)
- js省市联动,多版本,总有你喜欢的
- sqlzoo练习答案--SUM and COUNT
- Java反射初步学习
- 面试笔试技巧
- Windows下更改MySQL数据库的存储位置