24种设计模式--中介者模式【Mediator Pattern】
各位好,大家都是来自五湖四海,都要生存,于是都找了个靠山——公司,给你发薪水的地方,那公司就要想尽办法盈利赚钱,盈利方法则不尽相同,但是作为公司都有相同三个环节:采购、销售和库存,这个怎么说呢?比如一个软件公司,要开发软件,需要开发环境吧, Windows 操作系统,数据库产品等,这你得买吧,那就是采购,开发完毕一个产品还要把产品推销出去,推销出去了大家才有钱赚,不推销出去大家都去喝西北风呀,既然有产品就必然有库存,软件产品也有库存,你总要拷贝吧,虽然是不需要占用库房空间,那也是要占用光盘或硬盘,这也是库存,再比如做咨询服务的公司,它要采购什么?采购知识,采购经验,这是这类企业的生存之本,销售的也是知识和经验,库存同样是知识和经验。尽然进销存是这么的重要,我们今天就来讲讲它的原理和设计,我相信很多人都已经开发过这种类型的软件,基本上都形成了固定套路,不管是单机版还是网络版,一般的做法都是通过数据库来完成相关产品的管理,相对来说还是比较简单的项目,三个模块之间的示意图如下:
我们从这个示意图上可以看出,三个模块是相互依赖的,基本上是你中有我,我中有你,为什么呢?我们就以一个终端销售商(什么是终端销售商?就是以服务最终客户为目标的企业,比如 XX 超市,国美电器等等)为例子,比如采购部门要采购 IBM 型号的电脑了,它是根据什么来决定采购的呢?根据两个要素:
销售情况。销售部门要反馈销售情况,畅销就多采购,滞销就不采购;
库存情况。即使是畅销产品,库存都有 1000 台了,每天才卖出去 10 台,还要采购吗?!
销售模块是企业的盈利核心,也是对其他两个模块有影响的:
库存情况。库房有货,才能销售,没货空手套白狼是不行的;
督促采购。在特殊情况下,比如一个企业客户一下子要卖 100 台电脑,你库存里只有 80 台,怎么办?催采购部门赶快采购呀!
同样的,库存管理也对其他两个模块有影响,库房是有容积限制的,不可能无限大,所以就有了清仓处理,那就要求采购部门别采购了,同时销售部门赶快打折销售。
从以上分析来看,这三个模块都是有自己的行为,并且与其他模块之间的行为产生关联关系,就类似我们在办公室中的同事,大家各干各的活,但是彼此之间还是有交叉的,于是乎大家之间就产生紧密耦合,也就是一个团队。我们先来实现这个进销存,先看类图:
Purchase 负责采购管理,buyIBMComputer 是指定了采购 IBM 电脑,refuseBuyIBM 是不再采购 IBM 了 ,源代码如下:
package com.pattern.mediator; 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电脑");
} }
Purchase 定义了采购电脑的一个标准,如果销售情况比较好,大于 80 台,你让我采购多少我就采购多少;销售情况不好,你让我采购 100 台,我就采购 50 台,对折采购。电脑采购完毕了,肯定要放到库房中,因此要调用库存的方法,增加库存电脑数量。我们继续来看库房 Stock 类:
package com.pattern.mediator; 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();
}
}
库房中的货物数量肯定有增加和减少了,同时库房还有一个容量显示,达到一定的容量后就要求对一些商品进行折价处理,腾出更多的空间容纳新产品,于是就有了 clearStock 方法,既然是清仓处理肯定就要折价销售了,于是在 Sale 这个类中就有了 offSale 方法,我们来看 Sale 源代码:
package com.pattern.mediator; import java.util.Random; 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());
} }
Sale 类中的 getSaleStatus 是获得销售情况,这个当然要出现在 Sale 类中了,记住恰当的行为放到恰当的类中,销售情况当然只有销售人员才能反馈出来了,通过百分制的机制衡量销售情况。我们再来看场景类是怎么运行的:
package com.pattern.mediator; public class Client { 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();
} }
我们在场景类中模拟了三种人员类型的活动:采购人员采购电脑,销售人员销售电脑,库管员管理库存。
运行结果也是我们期望的,三个不同类型的参与者完成了各自的活动。但是…但是…,你难道就没有发现这三个类间是彼此关联的吗?每个类都与其他两个类产生了关联关系,迪米特法则教育我们“每个类只和朋友类交流”,这个朋友类可不是越多越好,越多耦合性越大,改一个对象而要修改一片对象,这可不是面向对象设计所期望的,而且这还是就三个模块的情况,比较简单的一个小项目,如果有十个八个这样的模块是不是就要歇菜了,我们把进销存扩充一下,如下图的情况:
是不是看到一个蜘蛛网的结构,这个别说是编写程序了,就是给人看估计能让一大批的人昏倒!每个对象都要和其他的几个对象交流,对象越多,每个对象要交流的成本也就越多了,就单独维护这些对象的交流基本上就能让一大批程序员望而却步,这明摆着不是人干的活嘛!从这方面来,我们已经发现设计的缺陷,作为一个架构师,发现缺陷就要想办法来修改,我们思考一下,怎么来修改。
大家都是学计算机的,应该在上学的时候讲过一些网络的基本知识,还记得网络拓扑有几种类型吗?总线型,环型,星型,等等,我们来想想星型拓扑是什么什么样子的,如下图:
星型网络拓扑中每个计算机通过交换机和其他计算机进行数据交换,各个计算机之间并没有直接出现交互的情况,结构简单,而且稳定,只要中间那个交换机不瘫痪,整个网络就不会发生大的故障,公司和网吧一般都采用星型网络,那也说明星型拓扑是深得民心,那我们来想想是不是可以把这种星型结构引入到我们的设计中呢?说干就干,我们先画一个示意图:
加入了一个中介者作为三个模块的交流核心,每个模块之间不再相互交流,要交流就通过中介者进行,每个模块只负责自己的业务逻辑,不属于自己的则丢给中介者来处理,看类图:
建立了两个抽象类 AbstractMediator 和 AbstractColeague,每个对象只是与中介者 Mediator 之间产生依赖,与其他对象之间没有直接的关系,AbstractMediator 的作用是把中介者的抽象定义,定义了一个抽象方法 execute,我们来看源代码:
package com.pattern.mediator.advance; public abstract class AbstractMediator {
protected Purchase purchase;
protected Sale sale;
protected Stock stock; // 构造函数
public AbstractMediator(){
this.purchase = new Purchase(this);
this.sale = new Sale(this);
this.stock = new Stock(this);
} // 中介者最重要的方法,叫做事件方法,处理多个对象之间的关系
public abstract void execute(String str, Object... objects); }
我们再来看具体的中介者,中介者可以根据业务的要求产生多个中介者(一般情况只有一个中介者),划分各个终结者的职责。我们来看 Mediator 源码:中介者 Mediator 又定义了多个 Private 方法,其目标是处理各个对象之间的依赖关系,即是说把原有一个对象要依赖多个对象的情况移到中介者的Private 方法中实现,在实际项目中,一般的做法是中介者按照职责进行划分,每个中介者处理一个或多个类似的关联请求。
我们再来看 AbstractColleague 源码:
package com.pattern.mediator.advance; public abstract class AbstractColleague {
protected AbstractMediator mediator; public AbstractColleague(AbstractMediator _mediator){
this.mediator = _mediator;
}
}
采购类 Purchase 的源码如下:
package com.pattern.mediator.advance; 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电脑");
}
}
Purchase 类是不是简化了很多,看着也清晰了很多,处理自己的职责,与外界有关系的事件处理则交给了中介者来完成。再来看 Stock 类:
package com.pattern.mediator.advance; 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");
}
}
以下为 Sale 类的源码:
package com.pattern.mediator.advance; import java.util.Random; 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");
}
}
再来看场景类的变化:
package com.pattern.mediator.advance; 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();
} }
在场景类中增加了一个中介者,然后分别传递到三个同事类中,三个类都具有相同的特性:只负责处理自己的活动(行为),与自己无关的活动就丢给中介者处理,程序运行的结果是相同的。从项目设计上来看,加入了中介者,设计结构清晰了很多,而且类间的耦合性大大减少,代码质量也有了很大的提升。
以上讲解的模式就是中介者模式,在多个对象依赖的情况喜爱,通过加入中介者角色,取消了多个对象的关联或依关系,减少了对象的耦合性,其通用类图为:
从类图中看,中介者模式有以下几部分组成:
抽象中介者(Mediator)角色:抽象中介者角色定义统一的接口用于各同事角色之间的通信。
具体中介者(Concrete Mediator)角色:具体中介者角色通过协调各同事角色实现协作行为,因此它必须依赖于各个同事角色。
同事(Colleague)角色:每一个同事角色都知道中介者角色,而且与其他的同事角色通信的时候,一定要通过中介者角色协作。每个同事类的行为分为两种:一种是同事本身的行为,比如改变对象本身的状态,处理自己的行为等等,这种方法叫做自发行为(Self-Method),与其他的同事类或中介者没有任何的依赖;第二种是是必须依赖中介者才能完成的行为,叫做依赖方法(Dep-Method)。
在前几张的讲解中,每个模式的类都已经给出,但是却没有给出通用的源代码,感觉这种方式不是很好,因此从本章开始,都加入通用源代码。中介者的通用源码结构如下所示,先看中介者 Mediator 类:
package com.pattern.mediator.advance2; 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(); }
在 Mediator 抽象类中我们只定义了同事类的注入,为什么使用同事实现类注入而不使用抽象类注入呢?那是因为同事类虽然有抽象,但是这个抽象也太抽象了,根本就没有每个同事类所必须要完成的业务方法,当然如果每个同事类都有相同的方法,比如 execute,handler 等,那当然注入抽象类,做到依赖倒转。
具体的中介者一般只有一个,其源码如下:
package com.pattern.mediator.advance2; public class ConcreteMediator extends Mediator { @Override
public void doSomething1() {
// 调用同事类的方法,只要是public方法都可以调用
super.c1.selfMethod1();
super.c2.selfMethod2();
} @Override
public void doSomething2() {
super.c1.selfMethod1();
super.c2.selfMethod2();
} }
中介者所具有的方法 doSomething1 和 doSomething2 都是比较复杂的业务逻辑,都是为同事类服务的,其实现是依赖了各个同事类来完成。
同事类的基类如下:
package com.pattern.mediator.advance2; public abstract class Colleague {
protected Mediator mediator; public Colleague(Mediator _mediator){
this.mediator = _mediator;
}
}
这个基类也是非常简单的,一般来说中介者模式中的抽象都是比较简单,是为了建立这个中介而服务的,同事实现类的源码如下:
package com.pattern.mediator.advance2; public class ConcreteColleague1 extends Colleague { // 通过构造函数传递中介者
public ConcreteColleague1(Mediator mediator) {
super(mediator);
} // 自有方法 self-method
public void selfMethod1(){
// 处理自己的业务逻辑
} // 依赖方法 dep-method
public void depMethod1(){
// 处理自己的业务逻辑
// 自己不能处理的业务逻辑,委托给中介者处理
super.mediator.doSomething1();
}
} package com.pattern.mediator.advance2; public class ConcreteColleague2 extends Colleague { // 通过构造函数传递中介者
public ConcreteColleague2(Mediator mediator) {
super(mediator);
} // 自有方法 self-method
public void selfMethod2(){
// 处理自己的业务逻辑
} // 依赖方法 dep-method
public void depMethod2(){
// 处理自己的业务逻辑
// 自己不能处理的业务逻辑,委托给中介者
super.mediator.doSomething2();
} }
为什么同事类要使用构造函数注入中介者而中介者使用 getter/setter 方式注入同事类呢?想过没有?那是因为同事类必须有中介者,而中介者可以只有部分同事类。
中介者模式的优点就是减少类间的依赖,把原有的一对多的依赖变成了一对一的依赖,同事类只依赖中介者,减少了依赖,当然也同时减低了类间的耦合。它的缺点呢就是中介者会膨胀的很大,而且逻辑会很复杂,因为所有的原本 N 个对象直接的相互依赖关系转换为中介者和同事类的依赖关系,同事类越多,中介者的逻辑就复杂。
中介者模式简单,但是简单不代表容易使用,这是 23 个模式中最容被误用的模式。我们知道在面向对象的编程中,对象和对象之间必然会有依赖关系,如果你写了一个类,这个类和其他类没有任何的依赖关系,其他类也不依赖这个类,那这个类就是一个“孤岛”嘛,在项目中就没有必要存在!这就像是人类,如果一个人永远独立生活,与任何人都没有关系,那这个人基本上就算是野人了——排除在人类这个定义之外。类之间的依赖关系是必然存在的,一个类依赖多个类的情况也是存在的,存在即合理,那是否可以说只要有多个依赖关系就考虑使用中介者模式呢?答案是否定的,中介者模式未必就能帮你把原本凌乱的逻辑整理的清清楚楚,而且中介者模式也是有缺点的,这个缺点在不当的使用时会被放大,比如原本就简单的几个对象依赖关系,如果为了使用模式而加入了中介者,必然导致中介者的逻辑复杂化,因此中介者模式的使用需要“量力而行”,那在什么环境下才使用中介者模式呢?中介者模式适用于多个对象之间紧密耦合,耦合的标准可以这样来衡量:在类图中出现了蜘蛛网状结构,在这种情况下一定要考虑使用中介者模式,有利于把蜘蛛网梳理为一个星型结构,使原本复杂混乱关系变得清晰简单。
中介者模式也叫做调停者模式,是什么意思呢?一个对象要和 N 多个对象交流,是不是就像对象间的战争,很混乱,你中有我,我中有你,那怎么才能调停这种矛盾呢?加入一个中心,所有的类都和中心交流,中心说怎么处理就这么处理,我们举一些在开发和生活中经常会碰到例子,再举四个例子如下:
机场调度中心。大家在每个机场都会看到有一个叫做“XX 机场调度中心”,这个是做什么用的呢?就是具体的中介者,调度每一架要降落和起飞的飞机,一架分机(同事类)飞到机场上空了,就询问(同事类方法)调度中心(中介者)“我是否可以降落”,“降落到那个跑道”,然后调度中心(中介者)查看其他飞机(同事类)情况,通知飞机降落,我们来设想一下,如果没有机场调度中心会是什么样子的:飞机到机场了,自己要先看看有没有飞机和自己一起降落的,有没有空跑道,停机位是否具备等等情况,这不是要了飞行员老命才怪!
MVC 框架。大家都应该使用过 Struts 吧,MVC 框架,其中的 C(Controller)就是一个中介者,叫做前端控制器(Front Controller),它的作用就是把 M(Model,业务逻辑)和 V(View,视图)隔离开,协调 M和 V 协同工作,把 M 运行的结果和 V 代表的视图融合成一个前端可以展示的页面,减少 M 和V 的依赖关系。MVC 框架已经成为一个非常流行、成熟的开发框架,这也是中介者模式优秀的一个体现。
C/S 结构。C/S 结构的应用也是一个典型的中介者模式,比如 MSN,张三发一个消息给李四,其过程应该是这样的:张三发送消息,MSN 服务器(中介者)接受到消息,查找李四,把消息发送到李四,同时通知张三,消息已经发送,在这里 MSN 服务器就是一个中转站,负责协调两个客户端的信息交流,与此相反的就是 IPMSG(也叫飞鸽)没有使用中介者,直接使用了 UDP 广播的方式,每个客户端既是客户端也是服务端。
中介服务。现在中介服务非常多,比如租房中介,出国中介,这些也都是中介模式的具体体现,比如你去租房子,如果没有房屋中介,你就必须一个一个小区的找,看看有没有空房子,有没有适合自己的房子,找到房子后还要和房东签合约,自己检查房屋的家具、水电煤等,有了中介后,你就省心多了,找中介,然后安排看房子,看中了,签合约,中介帮你检查房屋家具、水电煤等等。这也是中介模式的实际应用。
不知道大家有没有发觉,这章讲的中介者模式很少用到接口或者抽象类,这与依赖倒转原则是冲突的,确实是,这是什么原因呢?首先说同事类,既然是同事类而不是兄弟类(有相同的血缘)那也说明这些类之间是协作关系,完成不同的任务,处理不同的业务,所以不能在抽象类或接口中严格定义同事类必须具有的方法(从这点也可以看出继承是侵入性的),这是不合适的,就像你我是同事,虽然我们大家都是朝九晚五的上班,但是你跟我干的活肯定不同,不可能抽象出一个父类统一定义同事所必须有的方法,当然也有办法定义,每个同事都要吃饭,都要上厕所,那把这些最基本的信息封装到抽象中是可以的,但问题是这些最基本行为或属性是中介者模式要关心的嘛?如果两个对象不能提炼出共性,那就不要刻意的去追求两者的抽象,抽象只要定义出模式需要的角色即可。其次是中介者的原因,在一个项目中中介者模式可能被多个模块采用,每个中介者所围绕的同事类各不相同,你能抽象出一个具有共性的中介者吗?不可能,一个中介者抽象类一般只有一个实现者,除非中介者逻辑非常大,代码量非常高,这时才会出现多个中介者的情况,所有,对中介者来说,抽象已经没有太多的必要。
中介者模式是一个非常好的封装模式,也是一个很容易被滥用的模式,一个对象依赖几个对象是再正常不过的事情,但是纯理论家就会要求使用中介者模式来封装这种依赖关系,这是非常危险的信号,使用中介模式就必然会带来中介者的膨胀问题,这在一个项目中是很不恰当的,那到底在什么情况下使用中介者模式呢?大家可以在如下的情况下尝试使用中介者模式:
1、 N 个对象之间产生了相互的依赖关系,其中 N 大于 2,注意是相互的依赖;
2、 多个对象有依赖关系,但是依赖的行为尚不确定或者有发生改变的可能,在这种情况下一般建议采用中介者模式,降低变更引起的风险扩散;
3、 产品开发。其中一个明显的例子就是 MVC 框架,把这个应用到产品中,可以提升产品的性能和扩展性,但是作为项目开发就未必,项目是以交付;
24种设计模式--中介者模式【Mediator Pattern】的更多相关文章
- 23种设计模式--中介者模式-Mediator Pattern
一.中介者模式的介绍 中介者模式第一下想到的就是中介,房子中介,婚姻中介啊等等,当然笔者也希望来个婚姻中介给我介绍一个哈哈哈,,回归正题中介者模式分成中介者类和用户类,根据接口编程的方式我们再 ...
- 二十四种设计模式:中介者模式(Mediator Pattern)
中介者模式(Mediator Pattern) 介绍用一个中介对象来封装一系列的对象交互.中介者使各对象不需要显式地相互引用,从而使其耦合松散,而且可以独立地改变它们之间的交互. 示例有一个Messa ...
- 设计模式系列之中介者模式(Mediator Pattern)——协调多个对象之间的交互
说明:设计模式系列文章是读刘伟所著<设计模式的艺术之道(软件开发人员内功修炼之道)>一书的阅读笔记.个人感觉这本书讲的不错,有兴趣推荐读一读.详细内容也可以看看此书作者的博客https:/ ...
- 乐在其中设计模式(C#) - 中介者模式(Mediator Pattern)
原文:乐在其中设计模式(C#) - 中介者模式(Mediator Pattern) [索引页][源码下载] 乐在其中设计模式(C#) - 中介者模式(Mediator Pattern) 作者:weba ...
- 中介者模式(Mediator Pattern)
用于减少多个对象或类之间的通信复杂性. 此模式提供了一个中介类,它通常处理不同类之间的所有通信,并支持通过松散耦合来维护代码.中介者模式属于行为模式类别. 实现实例 在这里通过一个聊天室的示例来演示中 ...
- 4.7 《硬啃设计模式》 第24章 麻烦的多角关系 - 中介者模式(Mediator Pattern)简介
在Windows程序中,有时候界面控件之间的交互会很麻烦,如:A控件显示什么的时候,B控件要显示什么,另外C控件要不可用,同样其它控件也会有类似的复杂要求.控件与控件之间很容易形成复杂的多角关系了.现 ...
- [设计模式] 17 中介者模式 Mediator Pattern
在GOF的<设计模式:可复用面向对象软件的基础>一书中对中介者模式是这样说的:用一个中介对象来封装一系列的对象交互.中介者使各对象不需要显式地相互引用,从而使其耦合松散,而且可以独立地改变 ...
- 18.中介者模式(Mediator Pattern)
using System; namespace Test { class Program { /// <summary> /// 中介者模式,定义了一个中介对象来封装一系列对象之间的交互关 ...
- 设计模式-中介者模式(Mediator)
场景分析: 众所周知,电脑有很多组成部分,如硬盘.内存.光驱.音频.键盘等,各个组件之间协同工作才能保证电脑的正常运行. 如果各个组件之间直接交互,可能会比较复杂,如下图: 将上面的各个组件抽象成类, ...
随机推荐
- git拉取远程分支并创建本地分支和Git中从远程的分支获取最新的版本到本地
git拉取远程分支并创建本地分支 一.查看远程分支 使用如下Git命令查看所有远程分支: git branch -r 二.拉取远程分支并创建本地分支 方法一 使用如下命令: git checkout ...
- Winform 注册机通用软件注册功能之建立有效的软件保护机制
本文转载:http://www.cnblogs.com/umplatform/archive/2013/01/23/2873001.html 众所周知,一些共享软件往往提供给使用者的是一个功能不受限制 ...
- 利用Chrome模拟访问移动端网页
很多网站都通过User-Agent来判断浏览器类型,如果是3G手机,显示手机页面内容,如果是普通浏览器,显示普通网页内容. 谷歌Chrome浏览器,可以很方便地用来当3G手机模拟器.在Windows的 ...
- NSDateFormatter 问题
NSDateFormatter *inputDateFormatter = [[NSDateFormatter alloc] init]; NSString *inputDateStr = @&quo ...
- httpclient模拟浏览器訪问站点
HttpClient 是 Apache Jakarta Common 下的子项目.能够用来提供高效的.最新的.功能丰富的支持 HTTP 协议的client编程工具包.而且它支持 HTTP 协议最新的版 ...
- Delphi获取目录下所有文件名
//获取一个文件夹下的所有文件 //不包括文件夹里面的文件 //ListBox1.Items:= searchfile('Z:\'); //注意,path后面要有'\'; function Sear ...
- SQL 学习与工作日常:语句积累
1.跨服务器连接数据表 --打开服务器配置'Ad Hoc Distributed Queries' --exec sp_configure 'show advanced options',1 --re ...
- myeclipse使用太卡问题
最近写html文件,修改内容时,就会反应好长时间,太卡. 原因:没修改一次,它就会自动校验. 解决方法:window——preferences——Editors——Text Editors ——spe ...
- ubuntu下使用quick2wire控制RespberryPi2的I2C
首先,开启树莓派的I2C驱动: 查看I2C驱动是否已经被加载:ls /dev -l | grep i2c,如果有形如 i2c-x 的显示结果表明驱动已经加载,否则驱动没有加载,需要进行如下操作: 修改 ...
- 通过Workbook类 生成Excel导出数据
需求: 实现错误信息生成Excel保存到本地让用户查看. 刚开始使用了微软自带的Microsoft.Office.Interop.Excel类库. Microsoft.Office.Interop.E ...