@cppexplore
再看了下你的實(shí)現(xiàn)，好像我們討論的著重點(diǎn)不一樣。
1. 你的系統(tǒng)里，是不是首先有這樣一個需求：
因?yàn)槟撤N原因（分布式，進(jìn)程間，無鎖線程），消息的發(fā)送者不能直接調(diào)用消息處理函數(shù)，而是傳送一個消息代碼來表示需要處理的類型？
消息代碼即是win32中的WM_XX或者你的系統(tǒng)中的 enum MsgType { MSG_TYPE_1＝65, ... };
2. 消息的處理者，又需要按照約定（即消息代碼的含義），將其映射到某個處理函數(shù)中。
如 win32 中
switch (message) {
case WM_XXX:
return OnXXX(hwnd,message,wparam,lparam);
...
}
或者你的系統(tǒng)中的
switch(msg->type)
{
case MSG_TYPE_1:
do_msg_type_1_();
break;
case MSG_TYPE_2:
do_msg_type_2_();
break;
..
default:
do_default_msg_();
break;
}
在這一步，確實(shí)是你的實(shí)現(xiàn)方式時間效率比較高。
但是在win32中， 這樣做不太現(xiàn)實(shí) …… 1000多個消息，表格就要包含1000多項(xiàng)，而且大多都是DefWndProc。
并且，在這一步中，虛函數(shù)根本就提供不了任何幫助。
你的著重點(diǎn)在這一步？
3. 你想實(shí)現(xiàn)一個消息處理者B，它對大多數(shù)消息的處理方式同A一樣，這時候如何盡可能的使用A的實(shí)現(xiàn)？
（暫不說依賴于某實(shí)現(xiàn)是不太恰當(dāng)?shù)脑O(shè)計(jì)，在MFC中多如牛毛……）
我的著重點(diǎn)在這里，我對處理這步的觀點(diǎn)是： 『消息類型做數(shù)組下標(biāo)了，直接定位取處理函數(shù)』與『覆寫虛函數(shù)』相比，時空效率是相同的，我覺得后者更容易理解和擴(kuò)展。