设计模式 您所在的位置:网站首页 中介者模式是什么原则 设计模式

设计模式

2023-12-25 21:13| 来源: 网络整理| 查看: 265

@

目录什么是中介者模式?为什么要用中介者模式?使用中介者模式前使用中介者模式后中介者模式的优缺点中介者模式适用场景

什么是中介者模式?

中介者模式的定义:

Define an object that encapsulates how a set of objects interact.Mediator promotes loose coupling by keeping objects from referring to each other explicitly,and it lets you vary their interaction independently.(用一个中介对象封装一系列的对象 交互,中介者使各对象不需要显示地相互作用,从而使其耦合松散,而且可以独立地改变它 们之间的交互。)

中介模式通用类图如下:

图14-1:中介者模式通用类图

在这里插入图片描述

中介者模式由以下几部分组成:

● Mediator(抽象中介者):它定义一个接口,该接口用于与各同事对象之间进行通信。 ● ConcreteMediator(具体中介者):它是抽象中介者的子类,通过协调各个同事对象来实现 协作行为,它维持了对各个同事对象的引用。 ● Colleague(抽象同事类):它定义各个同事类公有的方法,并声明了一些抽象方法来供子类 实现,同时它维持了一个对抽象中介者类的引用,其子类可以通过该引用来与中介者通信。 ● ConcreteColleague(具体同事类):它是抽象同事类的子类;每一个同事对象在需要和其他同事对象通信时,先与中介者通信,通过中介者来间接完成与其他同事类的通信;在具体同事类中实现了在抽象同事类中声明的抽象方法。。每个同事类的行为分为两种:一种是同事本身的行为,比如改变对象本身的 状态,处理自己的行为等,这种行为叫做自发行为(Self-Method),与其他的同事类或中介 者没有任何的依赖;第二种是必须依赖中介者才能完成的行为,叫做依赖方法(Dep- Method)。

中介者模式的核心在于中介者类的引入,在中介者模式中,中介者类承担了两方面的职责:

(1) 中转作用(结构性):通过中介者提供的中转作用,各个同事对象就不再需要显式引用其他同事,当需要和其他同事进行通信时,可通过中介者来实现间接调用。该中转作用属于中 介者在结构上的支持。 (2) 协调作用(行为性):中介者可以更进一步的对同事之间的关系进行封装,同事可以一致的和中介者进行交互,而不需要指明中介者需要具体怎么做,中介者 根据封装在自身内部的协调逻辑,对同事的请求进行进一步处理,将同事成员之间的关系行为进行分离和封装。该协调作用属于中介者在行为上的支持。

中介者模式通用代码如下:

抽象中介者 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(); } 中介者:在具体中介者类中将调用同事类的方法,调用时可以增加一些自己的业务代码对调用进行控制。 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(); } } 抽象同事类 public abstract class Colleague { protected Mediator mediator; public Colleague(Mediator _mediator) { this.mediator = _mediator; } } 具体同事类: public class ConcreteColleague1 extends Colleague { // 通过构造函数传递中介者 public ConcreteColleague1(Mediator _mediator) { super(_mediator); } // 自有方法 self-method public void selfMethod1() { // 处理自己的业务逻辑 } // 依赖方法 dep-method public void depMethod1() { // 处理自己的业务逻辑 // 自己不能处理的业务逻辑,委托给中介者处理 super.mediator.doSomething1(); } } public class ConcreteColleague2 extends Colleague { // 通过构造函数传递中介者 public ConcreteColleague2(Mediator _mediator) { super(_mediator); } // 自有方法 self-method public void selfMethod2() { // 处理自己的业务逻辑 }// 依赖方法 dep-method public void depMethod2() { // 处理自己的业务逻辑 // 自己不能处理的业务逻辑,委托给中介者处理 super.mediator.doSomething2(); } } 为什么要用中介者模式?

现在有一个进销存的场景:

图14-2:进销存示意图

在这里插入图片描述 三个模块是相互依赖的。以一个终端销售商(以服务最终客户为目标的企业,比如某某超市、某某商店等)为例,采购部门要采购IBM的电 脑,它根据以下两个要素来决定采购数量。

● 销售情况: 销售部门要反馈销售情况,畅销就多采购,滞销就不采购。 ● 库存情况: 即使是畅销产品,库存都有1000台了,每天才卖出去10台,也就不需要再采购了! 销售模块是企业的赢利核心,对其他两个模块也有影响: ● 库存情况: 库房有货,才能销售,空手套白狼是不行的。 ● 督促采购: 在特殊情况下,比如一个企业客户要一次性购买100台电脑,库存只有80台,这时需要催促采购部门赶快采购!

库存管理也对其他两个模块有影响。库房是有容积限制的,不可能无限大,所 以就有了清仓处理,那就要求采购部门停止采购,同时销售部门进行打折销售。

使用中介者模式前

从以上分析来看,这三个模块都有自己的行为,并且与其他模块之间的行为产生关联。设计 的类图如下:

图14-3: 简单的进销存类图

在这里插入图片描述

Purchase负责采购管理,buyIBMComputer指定了采购IBM电脑,refuseBuyIBM是指不再采 购IBM。

具体实现:

采购管理: public class Purchase { // 采购IBM电脑 public void buyIBMcomputer(int number) { // 访问库存 Stock stock = new Stock(); // 访问销售 Sale sale = new Sale(); // 电脑的销售情况 int saleStatus = sale.getSaleStatus(); if (saleStatus > 80) { // 销售情况良好 System.out.println("采购IBM电脑:" + number + "台"); stock.increase(number); } else { // 销售情况不好 int buyNumber = number / 2; // 折半采购 System.out.println("采购IBM电脑:" + buyNumber + "台"); } } // 不再采购IBM电脑 public void refuseBuyIBM() { System.out.println("不再采购IBM电脑"); } } 库存管理: public class Stock { // 刚开始有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() { Purchase purchase = new Purchase(); Sale sale = new Sale(); System.out.println("清理存货数量为:" + COMPUTER_NUMBER); // 要求折价销售 sale.offSale(); //要求采购人员不要采购 purchase.refuseBuyIBM(); } } 销售管理: public class Sale { // 销售IBM电脑 public void sellIBMComputer(int number) { // 访问库存 Stock stock = new Stock(); // 访问采购 Purchase purchase = new Purchase(); if (stock.getStockNumber() < number) { // 库存数量不够销售 purchase.buyIBMcomputer(number); } System.out.println("销售IBM电脑" + number + "台"); stock.decrease(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() { // 库房有多少卖多少 Stock stock = new Stock(); System.out.println("折价销售IBM电脑" + stock.getStockNumber() + "台"); } } 场景类: public static void main(String[] args) { // 采购人员采购电脑 System.out.println("------采购人员采购电脑--------"); Purchase purchase = new Purchase(); purchase.buyIBMcomputer(100); // 销售人员销售电脑 System.out.println("\n------销售人员销售电脑--------"); Sale sale = new Sale(); sale.sellIBMComputer(1); // 库房管理人员管理库存 System.out.println("\n------库房管理人员清库处理--------"); Stock stock = new Stock(); stock.clearStock(); } }

我们在场景类中模拟了三种人员的活动:采购人员采购电脑,销售人员销售电脑,库管员管理库存。

运行结果如下: 在这里插入图片描述

OK,我们的功能都实现了,存在什么问题呢?

每个类都与其他两个类产生了关联关系。迪米特法则认为“每个类只 和朋友类交流”,这个朋友类并非越多越好,朋友类越多,耦合性越大,要想修改一个就得 修改一片,这不是面向对象设计所期望的,况且这还是仅三个模块的情况,属于比较简单的 一个小项目。我们把进销存扩展一下,如图所示:

图14-4:扩展后的进销存示意图

在这里插入图片描述

这样一来,整个模块可以说是很难开发和维护了,所以,这时候就要引入中介者模式。

使用中介者模式后

将之前的进销存结构重新设计:

图14-5:修改后的进销存示意图

在这里插入图片描述加入了一个中介者作为三个模块的交流核心,每个模块之间不再相互交流,要交流就通 过中介者进行。每个模块只负责自己的业务逻辑,不属于自己的则丢给中介者来处理,简化

了各模块之间的耦合关系,类图如图所示:

图14-6:修改后的进销存类图

在这里插入图片描述 建立了两个抽象类AbstractMediator和AbstractColeague,每个对象只是与中介者Mediator 之间产生依赖,与其他对象之间没有直接关系,AbstractMediator的作用是实现中介者的抽象 定义,定义了一个抽象方法execute。

实现如下:

抽象中介者: 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); } 具体中介者: 中介者Mediator定义了多个private方法,其目的是处理各个对象之间的依赖关系,就是说把原有一个对象要依赖多个对象的情况移到中介者的private方法中实现。在实际项目中, 一般的做法是中介者按照职责进行划分,每个中介者处理一个或多个类似的关联请求。 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(); } } 抽象同事类: 三个具体的实现类分别继承该抽象类 public abstract class AbstractColleague { protected AbstractMediator mediator; public AbstractColleague(AbstractMediator _mediator) { this.mediator = _mediator; } } 采购管理: 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电脑"); } } 库存管理: 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"); } } 销售管理: 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"); } } 场景类: 在场景类中增加了一个中介者,然后分别传递到三个同事类中,三个类都具有相同的特 性:只负责处理自己的活动(行为),与自己无关的活动就丢给中介者处理。 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(); } }

在多个对象依赖的情况下,通过加入中介者角色,取消了多个对象的关联或依赖关系, 减少了对象的耦合性。

中介者模式的优缺点

中介者模式的主要优点如下:

中介者模式简化了对象之间的交互,它用中介者和同事的一对多交互代替了原来同事之间 的多对多交互,一对多关系更容易理解、维护和扩展,将原本难以理解的网状结构转换成相 对简单的星型结构。 中介者模式可将各同事对象解耦。中介者有利于各同事之间的松耦合,我们可以独立的改 变和复用每一个同事和中介者,增加新的中介者和新的同事类都比较方便,更好地符合“开闭 原则”。 可以减少子类生成,中介者将原本分布于多个对象间的行为集中在一起,改变这些行为只 需生成新的中介者子类即可,这使各个同事类可被重用,无须对同事类进行扩展。

中介者模式的主要缺点如下:

在具体中介者类中包含了大量同事之间的交互细节,可能会导致具体中介者类非常复杂,使 得系统难以维护。 中介者模式适用场景

在以下情况下可以考虑使用中介者模式:

系统中对象之间存在复杂的引用关系,系统结构混乱且难以理解。 一个对象由于引用了其他很多对象并且直接和这些对象通信,导致难以复用该对象。 想通过一个中间类来封装多个类中的行为,而又不想生成太多的子类。可以通过引入中介者类来实现,在中介者中定义对象交互的公共行为,如果需要改变行为则可以增加新的具体 中介者类。

参考:

【1】:《设计模式之 禅》 【2】:《design-pattern-java》 【3】:《研磨设计模式》



【本文地址】

公司简介

联系我们

今日新闻

    推荐新闻

    专题文章
      CopyRight 2018-2019 实验室设备网 版权所有