更加符合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
{
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正是采用类似的表驱动设计来处理窗口消息,从而达到非常好的模块独立性和可扩展性,且处理效率方面也丝毫没有受影响。