Java事件处理模式

　　Java的事件模式是动态响应系统重要的基础，在图形界面领域的事件模式已经有很多文章介绍，但是在服务器端我们会碰到更多的事件模式，这里本人试图总结一下：

　　事件直接驱动模式
　　事件模式的第一个要求就是性能的要求，需要直接而且快，Command模式是必须经常使用的，主要适合于迅速处理 前台的命令，Command模式往往是系统架构的重要部分，也是流程控制的主要模式。

　　Command模式经常Java的Reflect一起使用，因为系统的事件处理系统是处于动态变化的，随着功能要求扩展，就可能有动态变化事件处理响应系统，以Struts中action为例，我们知道，Structs的一个主要配置文件是struts-config.xml 如下：

<struts-config>
　　 <action-mappings>
　　　　 <action path="/login" type="com.javapro.struts.LoginAction"/>
　　　　 <action path="/logout" type="com.javapro.struts.LogoutAction"/>
　　 </action-mappings>
</struts-config>

　　它实际是个command和event的映射关系，通过这个配置文件，运行时动态装载相应的Action，完成Command模式， 我们检查LoginAction代码，就可以看出Command模式的基本特征：

　　public final class LoginAction extends Action {
　　 　　public ActionForward execute(ActionMapping mapping,
　　　　 　　ActionForm form, HttpServletRequest request, HttpServletResponse 　　　　　　response)
　　　　 throws Exception {
　　　　　　　　 .................
　　 　}
　}

　　很明显，典型的Command模式需要有一个接口.接口中有一个统一的方法，这里统一的方法就是execute;

　　比如我们有个实时系统，客户段向服务器发出不同编码代号，意味着不同的请求，不同的请求有不同的Handler进行 处理，Handler接口是:

　　public class Handler{

　　 　　public byte[] handleRequest();

　　}

　　不同性质的处理过程继承这个Handler接口，如负责进入系统的处理过程

　　public class EnterHandler implements Handler{

　　 public byte[] handleRequest(){
　　 //具体业务处理
　　 ......
　　 }

　}

　　调用Handler时是:

　　//从cache中获取这个requestId对应的Handler
　　Handler handler = (Handler)cache.get(new Integer(reqId));
　　//调用handler的统一方法handleRequest()
　　byte[] outInf = handler.handleRequest();

　　以上是常用的一个事件驱动模式。它的特点是靠一个事件直接启动对应的事件处理器。

　　　Chain of Responsibility职责链模式也应该属于这类，当事件到达后，让这个事件在我们提供的一批处理器中逐个挑选适合的处理器进行处理，这个模式缺点是显然的，性能丧失在逐个挑选 上，一般不推荐使用，这个模式适合在我们无法预知发生的事件内容时使用，因为不知道发生事件的具体情况， 我们就无法在程序运行前事先为其指派相应的处理器，只能靠运行时，事件自己去摸索“撞运气”。