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

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

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

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

用中介者模式解决该问题即可设计以下几个类：
同事：Colleague
具体同事：ConcreteColleagueA(魏)，ConcreteColleagueB(蜀)， ConcreteColleagueC(吴)
中介者：Mediator(信使)
Colleague类：

/**
 * 同事类
 * 定义了具体同事，交战双方需要实现的方法
 * @author CarmenCai
 *
 */
public interface Colleague {
	//需要中介者转达的信息
	public void giveMes(String[] mes);
	//接收到的信息
	public void receiverMes(String mes);
	//具体同事的名字
	public void setName(String name);
	//得到具体同事的名字
	public String getName();

}

其中一个具体的ConcreteColleague类：

/**
 * 具体同事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;
	}
}

Mediator(中介者)：

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

}

用于连接三个国家，并送出谈判信息ConcreteMediator(具体中介者)：

/**
 * 具体中介者类
 * 实现中介者接口
 * @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]);
				}
		}
	}
}

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

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

        在日常生活中，我们熟悉的十字路口的交通信号就是一个由中介者模式设计的。在十字路口，东西走向和南北走向各有一组由红黄绿组成的信号灯。而这些灯的开闭又统一由一的控制器（中介者）控制完成。
        以下是我的模拟交通信号的UML类图结构

       在做这个模拟交通信号项目时，首先要熟悉交通信号灯的规则，即：东西绿灯亮，南北红灯亮；东西红灯，南北黄灯；东西红灯，南北绿灯。
        因此，每一个信号灯都应该有on();和off();的方法，而中介者即对交通规则的设计，是通过一个线程来控制路灯的关闭，另外，中介者一个重要的方法就是要注册控制的几盏信号灯。当然还可以加入一些附带的功能，如根据不同路段，设计红绿灯的交替时间，这也是是通过一个中介者模式建立起来的。最后，路面的显式界面是一个大类，是几个类的集合。详细代码请见附件  TransportSignLight.rar。
        用中介者模式做的模拟交通信号的界面：

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

在23种设计模式中，除了中介模式外，现在用到比较多的还有工厂模式：
命令模式：
命令模式结构的四种角色：
接收者（Receiver）:负责执行与请求相关的操作
命令（Command）接口:规定用来封装“请求”的若干个方法
具体命令（ConcreteCommand）:具体命令是实现命令接口 的实例
请求者（Invoker）:请求者是一个包含命令接口的一个实例。请求者中的Command接口的变量可以存放任何具体命令的引用。请求者负责调用具体命令，让具体命令执行那些封装了请求的操作。