Java的事件模式是動態(tài)響應(yīng)系統(tǒng)重要的基礎(chǔ)，在圖形界面領(lǐng)域的事件模式已經(jīng)有很多文章介紹，但是在服務(wù)器端我們會碰到更多的事件模式，這里本人試圖總結(jié)一下：
事件直接驅(qū)動模式
事件模式的第一個要求就是性能的要求，需要直接而且快，Command模式是必須經(jīng)常使用的，主要適合于迅速處理 前臺的命令，Command模式往往是系統(tǒng)架構(gòu)的重要部分，也是流程控制的主要模式。
Command模式經(jīng)常Java的Reflect一起使用，因為系統(tǒng)的事件處理系統(tǒng)是處于動態(tài)變化的，隨著功能要求擴展，就可能有動態(tài)變化事件處理響應(yīng)系統(tǒng)，以Struts中action為例，我們知道，Structs的一個主要配置文件是struts-config.xml 如下：
它實際是個command和event的映射關(guān)系，通過這個配置文件，運行時動態(tài)裝載相應(yīng)的Action，完成Command模式， 我們檢查LoginAction代碼，就可以看出Command模式的基本特征：
public final class LoginAction extends Action {
public ActionForward execute(ActionMapping mapping,
ActionForm form, HttpServletRequest request, HttpServletResponse response)
throws Exception {
.................
}
}
很明顯，典型的Command模式需要有一個接口.接口中有一個統(tǒng)一的方法，這里統(tǒng)一的方法就是execute;
比如我們有個實時系統(tǒng)，客戶段向服務(wù)器發(fā)出不同編碼代號，意味著不同的請求，不同的請求有不同的Handler進行 處理，Handler接口是:
public class Handler{
public byte[] handleRequest();
}
不同性質(zhì)的處理過程繼承這個Handler接口，如負責進入系統(tǒng)的處理過程
public class EnterHandler implements Handler{
public byte[] handleRequest(){
//具體業(yè)務(wù)處理
......
}
}
調(diào)用Handler時是:
//從cache中獲取這個requestId對應(yīng)的Handler
Handler handler = (Handler)cache.get(new Integer(reqId));
//調(diào)用handler的統(tǒng)一方法handleRequest()
byte[] outInf = handler.handleRequest();
以上是常用的一個事件驅(qū)動模式。它的特點是靠一個事件直接啟動對應(yīng)的事件處理器。
Chain of Responsibility職責鏈模式也應(yīng)該屬于這類，當事件到達后，讓這個事件在我們提供的一批處理器中逐個挑選適合的處理器進行處理，這個模式缺點是顯然的，性能喪失在逐個挑選 上，一般不推薦使用，這個模式適合在我們無法預知發(fā)生的事件內(nèi)容時使用，因為不知道發(fā)生事件的具體情況， 我們就無法在程序運行前事先為其指派相應(yīng)的處理器，只能靠運行時，事件自己去摸索“撞運氣”。
事件直接驅(qū)動模式
事件模式的第一個要求就是性能的要求，需要直接而且快，Command模式是必須經(jīng)常使用的，主要適合于迅速處理 前臺的命令，Command模式往往是系統(tǒng)架構(gòu)的重要部分，也是流程控制的主要模式。
Command模式經(jīng)常Java的Reflect一起使用，因為系統(tǒng)的事件處理系統(tǒng)是處于動態(tài)變化的，隨著功能要求擴展，就可能有動態(tài)變化事件處理響應(yīng)系統(tǒng)，以Struts中action為例，我們知道，Structs的一個主要配置文件是struts-config.xml 如下：
它實際是個command和event的映射關(guān)系，通過這個配置文件，運行時動態(tài)裝載相應(yīng)的Action，完成Command模式， 我們檢查LoginAction代碼，就可以看出Command模式的基本特征：
public final class LoginAction extends Action {
public ActionForward execute(ActionMapping mapping,
ActionForm form, HttpServletRequest request, HttpServletResponse response)
throws Exception {
.................
}
}
很明顯，典型的Command模式需要有一個接口.接口中有一個統(tǒng)一的方法，這里統(tǒng)一的方法就是execute;
比如我們有個實時系統(tǒng)，客戶段向服務(wù)器發(fā)出不同編碼代號，意味著不同的請求，不同的請求有不同的Handler進行 處理，Handler接口是:
public class Handler{
public byte[] handleRequest();
}
不同性質(zhì)的處理過程繼承這個Handler接口，如負責進入系統(tǒng)的處理過程
public class EnterHandler implements Handler{
public byte[] handleRequest(){
//具體業(yè)務(wù)處理
......
}
}
調(diào)用Handler時是:
//從cache中獲取這個requestId對應(yīng)的Handler
Handler handler = (Handler)cache.get(new Integer(reqId));
//調(diào)用handler的統(tǒng)一方法handleRequest()
byte[] outInf = handler.handleRequest();
以上是常用的一個事件驅(qū)動模式。它的特點是靠一個事件直接啟動對應(yīng)的事件處理器。
Chain of Responsibility職責鏈模式也應(yīng)該屬于這類，當事件到達后，讓這個事件在我們提供的一批處理器中逐個挑選適合的處理器進行處理，這個模式缺點是顯然的，性能喪失在逐個挑選 上，一般不推薦使用，這個模式適合在我們無法預知發(fā)生的事件內(nèi)容時使用，因為不知道發(fā)生事件的具體情況， 我們就無法在程序運行前事先為其指派相應(yīng)的處理器，只能靠運行時，事件自己去摸索“撞運氣”。