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職責鏈模式也應該屬于這類，當事件到達后，讓這個事件在我們提供的一批處理器中逐個挑選適合的處理器進行處理，這個模式缺點是顯然的，性能喪失在逐個挑選 上，一般不推薦使用，這個模式適合在我們無法預知發生的事件內容時使用，因為不知道發生事件的具體情況， 我們就無法在程序運行前事先為其指派相應的處理器，只能靠運行時，事件自己去摸索“撞運氣”。