用查表法代替switch-case

更加符合close-open原则，即对修改封闭，对扩展开放，增加代码的稳定性及可维护性。

以Windows的消息处理函数为例，典型的Win32 API程序中这样处理消息：
LRESULT CALLBACK WindowProc(HWND hwnd,
    UINT uMsg,
    WPARAM wParam,
    LPARAM lParam
)
{
    LRESULT lResult = 0;
    switch(uMsg)
    {
    case WM_SIZE:
         lResult = OnSize(wParam, lParam);
         break;
    case WM_SHOWWINDOW:
         lResult = OnShow(wParam, lParam);
         break;
    case WM_PAINT:
         lResult = OnPaint(wParam, lParam);
         break;
    default:
         lResult = DefWindowProc(hwnd, uMsg, wParam, lParam);
         break;
    }
    return lResult;
}

LRESULT OnSize(WMPARAM, LPARAM){...}
LRESULT OnShow(WMPARAM, LPARAM){...}
LRESULT OnPaint(WMPARAM, LPARAM){...}
以上代码整齐而清新，基本上没有什么毛病。但很显然每加一个消息，都需要修改WindowProc中的case语句块，尤其是当case非常多的情况下，找到case的尾部并非一件容易的事情。如果情况更糟一点，case中的代码并非上面演示的如此整洁，正确添加一个case并非易事，而且如果在case后忘了break，后果则可能是无法预料的。要知道每次修改都是一次冒险，这也是要求代码对修改封闭这一设计原则的来由。更好的代码：
struct MessageMapEntry
{
    UINT uMsg;
    LRESULT (*handler)(WPARAM, LPARAM);
};
MessageMapEntry MessageMap[] =
{
    {WM_SIZE, OnSize},
    {WM_SHOWWINDOW, OnShow},
    {WM_PAINT, OnPaint},
};
LRESULT CALLBACK WindowProc(HWND hwnd,
    UINT uMsg,
    WPARAM wParam,
    LPARAM lParam
)
{
    for(int i=0; i<sizeof(MessageMap)/sizeof(MessageMap[0]); ++i)
    {
        if(MessageMap[i].uMsg == uMsg)
        {
            return MessageMap[i].handler(wParam, lParam);
        }
    }
    return DefWindowProc(hwnd, uMsg, wParam, lParam);
}
比较这两段代码，后者的逻辑代码仅8行，且不再随case的增加而增加，也就是说WindowProc这个函数对于修改已经封闭了。而每一个case只要在MessageMap数组中添加一个条目，所以对扩展是开放的。单从代码数量来说，一个case需要至少3行，而一个表目只需要1行，更少的代码行意味著更少的维护工作量，也意味著更小的出错概率。

另外，采用表驱动设计，可以促进模块化设计，因为它强制要求将每个表目的处理提取为独立的函数，而不是像switch-case一样允许将处理代码块直接嵌入case语句中。

MFC正是采用类似的表驱动设计来处理窗口消息，从而达到非常好的模块独立性和可扩展性，且处理效率方面也丝毫没有受影响。