从实例解析中介者模式--交通信号灯

[align=center][size=medium]从实例解析中介者模式--交通信号灯[/size][/align]
[size=small] 在学习JAVA过程中,我做过的第一个小有成就的项目是一个仿XP的画图板。因为是初次接触使用编程语言做一些自认为还比较实际的东西,所以我整个画图板,从开始写Swing界面,到最后的BMP保存完成,我用了近乎两个月的时间。记得初步完成(XP画板上的画笔工具实现,重绘完成)时,我的画板只有2个类DrawUI(画板的界面)和DrawListener(监听器),共682行代码,窗体类234行,画图监听器448行;现在,这个画板(新增了BMP功能)有2个包,共30个类,代码也就一千多行。整个画图板的功能并没有什么太大区别,但是代码的结构却发生了天翻地覆发变化。第一个版本出错时,只有我愿意话费两三个小时,甚至几天时间去查找错误,因为它是我写的;最后一个版本,已经给部分正在学画图板的同学拿去借鉴了,想必他们是看得懂的。这就是代码结构带来的区别。一段清晰明朗的代码,就如一头梳理顺畅的直发一样,不会给人“剪不断,理还乱”的烦恼。
因此,在着手写代码前,要学会设计代码之间的架构关系,搭建一个结实简明的框架结构。这种源自于建筑学的理论,被运用到软件领域,即设计模式(Design Pattern),它是面向对象语言中利用类和方法实现某个编程目标的方法。
人们根据面向对象的4个原则:
1、面向抽象原则
2、开闭原则:让设计对扩展开放,对修改关闭
3、多用组合少用继承
4、高内聚——低耦合原则
将软件的23种设计模式分为5类。[/size]
[align=center][img]http://dl.iteye.com/upload/attachment/0071/7239/9cb0cd18-c0b7-352d-a05a-9c76ba38c7d6.png[/img][/align]

[size=small] 在信息还不发达的中国,人与人之间的交流很局限,因此产生了很多的角色来调节这种信息不通的场面,如媒婆、信使等,都在人们的生活中起着重要作用。而在设计模式中,中介者模式就是这类实例的灵活运用。
中介者模式(Mediator Parttern):用一个对象来封装一系列的对象交互。中介者使各对象不需要显示相互引用,从而使其耦合松散,而且可以独立地改变他们之间的交互。
中介者模式的结构中包含的角色:
1、中介者(Mediator):中介者是一个interface ,该接口定义了用于同事对象之间进行通信的方法。
2、具体终结者(ConcreteMediator):实现中介者接口的类。需包含所有具体同事(ConcreteColleague)的引用:并通过实现中介者接口的方法来满足具体同事之间的通信请求
3、同事(Colleague):一个接口,规定了具体同时需要实现的方法
4、具体同事(ConcreteCplleague):实现同事接口,一个具体同事需要和其他具体同事交互时,只需将自己的请求通知给它所包含的具体中介者
假设有三国在交战:分别是魏、蜀、吴,现有如下交易,但是三个国家的关系正处于水深火热之中,因此,就需要一个中间人进行谈判信息的交换,及中介者。[/size]
[align=center][img]http://dl.iteye.com/upload/attachment/0071/7412/c0eeb491-5eea-3036-b209-6adec3b02ec4.png[/img][/align]

[size=small]用中介者模式解决该问题即可设计以下几个类:
同事:Colleague
具体同事:ConcreteColleagueA(魏),ConcreteColleagueB(蜀), ConcreteColleagueC(吴)
中介者:Mediator(信使)
Colleague类:[/size]
/**
* 同事类
* 定义了具体同事,交战双方需要实现的方法
* @author CarmenCai
*
*/
public interface Colleague {
//需要中介者转达的信息
public void giveMes(String[] mes);
//接收到的信息
public void receiverMes(String mes);
//具体同事的名字
public void setName(String name);
//得到具体同事的名字
public String getName();

}

[size=small]其中一个具体的ConcreteColleague类:[/size]
/**
* 具体同事A
* @author CarmenCai
*
*/
public class ColleagueA implements Colleague{
//姓名
String name;
//具体中介者
ConcreteMediator mediator;
/**
* 创建带有指定具体中介者的同事A
* @param mediator
*/
public ColleagueA(ConcreteMediator mediator){
this.mediator=mediator;
//注册该用户
mediator.registerColleague(this);
}
/**
* 得到姓名
*/
public String getName() {
return name;
}
/**
* 发送的信息
*/
public void giveMes(String[] mes) {
mediator.deliverMes(this, mes);
}
/**
* 接收的信息
*/
public void receiverMes(String mes) {
System.out.println(name+"收到的消息是:\n\t"+mes);
}
public void setName(String name) {
this.name=name;
}
}

[size=small]Mediator(中介者):[/size]
/**
* 中介者类
* @author CarmenCai
*
*/
public interface Mediator {
//注册具体同事用户
public void registerColleague(Colleague colleague);
//传达消息
public void deliverMes(Colleague colleague,String[] mes);

}

[size=small]用于连接三个国家,并送出谈判信息ConcreteMediator(具体中介者):[/size]
/**
* 具体中介者类
* 实现中介者接口
* @author CarmenCai
*
*/
public class ConcreteMediator implements Mediator{
//声明具体同事
ColleagueA colleagueA;
ColleagueB colleagueB;
ColleagueC colleagueC;
/**
* 注册同事
*/
public void registerColleague(Colleague colleague) {
if(colleague instanceof ColleagueA){
this.colleagueA=(ColleagueA) colleague;
}
if(colleague instanceof ColleagueB){
this.colleagueB=(ColleagueB) colleague;
}
if(colleague instanceof ColleagueC){
this.colleagueC=(ColleagueC) colleague;
}
}
/**
* 发送信息
* @param:colleague:同时对象
* @param:mes:传递的内容
*/
public void deliverMes(Colleague colleague, String[] mes) {
if(colleague==colleagueA){
if(mes.length>=2){
colleagueB.receiverMes(colleague.getName()+mes[0]);
colleagueC.receiverMes(colleague.getName()+mes[1]);
}
}
else if(colleague==colleagueB){
if(mes.length>=2){
colleagueA.receiverMes(colleague.getName()+mes[0]);
colleagueC.receiverMes(colleague.getName()+mes[1]);
}
}
else if(colleague==colleagueC){
if(mes.length>=2){
colleagueA.receiverMes(colleague.getName()+mes[0]);
colleagueB.receiverMes(colleague.getName()+mes[1]);
}
}
}
}

[size=small]以上是对中介模式具体结构的一个举例描述。

用以上描述,我们可以知道,中介者模式可以避免许多对象之间为了通信而相互显式引用,便于系统的维护工作。对于一个群众需求量比较大的交互网落,一个具体中介者模式就可以将大量有需求的群体联系起来,节约了资源。因此,对于对象以复杂的方式交互,例如A的对象调用B的对象,B中又用到了C的对象,C要调用A的对象,对于这种情况,就可以用中介者模式,减轻各个类之间的依赖程度,便于理解和调试差错。

在日常生活中,我们熟悉的十字路口的交通信号就是一个由中介者模式设计的。在十字路口,东西走向和南北走向各有一组由红黄绿组成的信号灯。而这些灯的开闭又统一由一的控制器(中介者)控制完成。
以下是我的模拟交通信号的UML类图结构[/size]
[align=center][img]http://dl.iteye.com/upload/attachment/0071/7416/087a8aae-b18c-3976-8e73-3319aa5b0f23.jpg[/img][/align]
[size=small] 在做这个模拟交通信号项目时,首先要熟悉交通信号灯的规则,即:东西绿灯亮,南北红灯亮;东西红灯,南北黄灯;东西红灯,南北绿灯。
因此,每一个信号灯都应该有on();和off();的方法,而中介者即对交通规则的设计,是通过一个线程来控制路灯的关闭,另外,中介者一个重要的方法就是要注册控制的几盏信号灯。当然还可以加入一些附带的功能,如根据不同路段,设计红绿灯的交替时间,这也是是通过一个中介者模式建立起来的。最后,路面的显式界面是一个大类,是几个类的集合。详细代码请见附件 TransportSignLight.rar。
用中介者模式做的模拟交通信号的界面:[/size]
[align=center][img]http://dl.iteye.com/upload/attachment/0071/7418/3c56291f-6fea-38df-8e26-49c650b0eb90.jpg[/img][/align]

[size=medium]
从以上实例中可以总结出,中介者模式无非是在较多的对象中添加一个管理者,对这些对象进行统一管理,并给这些需要相互联系的对象提供交流的通道和途径,实现传递信息的功能。

在23种设计模式中,除了中介模式外,现在用到比较多的还有工厂模式:
命令模式:
命令模式结构的四种角色:
接收者(Receiver):负责执行与请求相关的操作
命令(Command)接口:规定用来封装“请求”的若干个方法
具体命令(ConcreteCommand):具体命令是实现命令接口 的实例
请求者(Invoker):请求者是一个包含命令接口的一个实例。请求者中的Command接口的变量可以存放任何具体命令的引用。请求者负责调用具体命令,让具体命令执行那些封装了请求的操作。
[/size]
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值