聊天室練習 - VIII. 事件驅動

事件驅動的優缺點於先前的文章已經描述過，在此就不再重複。僅以一個簡單的測試來檢驗啟動事件與事件執行的順序。
在ChatRoomMain.py，第130行之後插入

print 'return to CommandParser'

另外，在ChatRoomFrame.py，第81行之後插入

print 'enter event_TEXTDISPLAY handle'

當輸入對談訊息後，ChatRoomMain.CommandParser啟動事件event_TEXTDISPLAY，對應的事件執行在ChatRoomFrame.CmdTextDisplayHandle。列印出的訊息如下：

enter event_TEXTDISPLAY handle
return to CommandParser
enter event_TEXTDISPLAY handle
return to CommandParser
enter event_TEXTDISPLAY handle
return to CommandParser
enter event_TEXTDISPLAY handle
return to CommandParser
enter event_TEXTDISPLAY handle
return to CommandParser

從列印出的訊息可以看出，每次啟動事件（ChatRoomMain.py，第130行）後，總是先處理事件執行（ChatRoomFrame.py，第81 行），執行完後才再回到啟動事件處繼續執行（ChatRoomMain.py，第131行，print 'return to CommandParser'）。猜測啟動事件後的事件執行並不會獨立出一個thread來處理，而是如同函數呼叫般直接跳至call back function。因此ChatRoomMain.py，第130行

messenger.send(event_TEXTDISPLAY,[cmdItem['i'], cmdItem['param']])

可以看成

self.ChatRoomFrame.CmdTextDisplayHandle(cmdItem['i'], cmdItem['param'])

在聊天室練習中，由於環境較單純，使用事件驅動似乎沒得到明顯的好處。
假設一個遊戲過程中，不同階段都有不同的處理對談文字顯示的函數。在不使用事件驅動的方式下，呼叫端（例如此練習中的CommandParser）必須要以階段來判斷該執行哪個文字顯示函數，並且當文字顯示函數更動名稱時，例如改變函數名稱或是換到不同類別內，呼叫端也要跟著更新。
但若使用事件驅動的方式，呼叫文字顯示與執行文字顯示的函數間以一個事件名稱（例如此練習中的event_TEXTDISPLAY）當介面連接，只要執行文字顯示的函數綁到此事件名稱的call back function，就可以在不更動呼叫端程式碼的情形下改變執行文字顯示的函數。因此，使用事件驅動應該可以減少程式維護上的成本。

為了避免事件名稱的衝突，在此練習中統一將事件名稱定義在CommandInputLib.py的最後。



----

1. 操作方式
2. 程式架構
3. 網路設定、接收與傳送
4. Server - Client 間的傳輸協定
5. 傳輸命令格式
6. GUI
7. 中文輸入與顯示
8. 事件驅動