mfc中的消息莫是相对于虚函数表来说到底有什么优势？有人说是空间上面有好处。既可以省下长长的虚函数表的内存。比如：
 用虚函数的话，window的基类会是
 class window
 {
  virtual OnSize() = 0;
  virtual OnMove() = 0;
  virtual OnContextMenu() = 0;
  ……等等
 }
 可想而知，每个由此继承而来的子类将会负担多么大的虚函数表，光是windows自带的就有数十个之多。当然不可取。
 
 可是除此之外，似乎有一种观点是如果机器够快的话就可以采用虚函数的方法了，哪只不不过是ms在当年的无奈之举。嗬嗬，真的是这样吗？非也！
 其一、如果有自定义的消息怎么办？修改基类？
 其二、其实在窗口间互相传递消息可以看成是互相的请求服务，此服务被请求窗体可以响应，也可以不响应。这种灵活性是虚函数方法所无法取得的——如果不支持的话，嗬嗬，对不起，编译时便会报错了。请求方对于被请求方的所有要求仅仅是其是CCmdTarget的子类即可。怎么样，正所谓便宜实惠量又足啊。可就是不太好理解，所以ms提供了许多宏来做这件事情。 
 
 下面看一个具体的例子。这是一个关于treectrl操作的例子。这是一棵表示公司组织的树，上面的节点有
 公司
    ----人事科
          -----张三
          -----李四 
    ----采购 
            -----王二
            -----麻子
 
 即三类节点，公司、科室、员工
 
 当客户右击鼠标时，对于不同的节点弹出的菜单当然是不同的。 
 做法1、判断三种节点的图标，（假定用不同的图标显示不同节点）然后针对不同的情况弹出菜单。这种方法对于显然不妥，有点像经典的
 if ( obj.typeid == ...)
  do something
 else if ( obj.typeid == .. )
  do somthine else ...
 结果就是在treectrl的代码中充满了这样的判断代码
 
 做法2、有class Company, class office, class person，均从CCmdTarget继承。当insert treeitem的时候，产生对象，将其指针和插入的item联系起来，方法可以采用SetItemData（对象的指针），这样的话，处理弹出菜单的方法就变为
 treectrl::OnContextMenu(...)
 {
  CCmdTarget* p = GetItemData(hSelItem);
  p->sendcommand(wm_contextmenu, point)
 }
 这样就ok了。但是有一个缺点，占用太多的内存了！每个item都有多出sizeof(CCmdTarget)，有点过分。
 再改进——做法3
 class Company, office, person不变，
 但增加他们的工厂类
 
 class treeitemor
 {
  virtual CCmdTarget* CreateItem() = 0;
 }
 class Companyor
 {
  long m_ID;
  virtual CmdTarget* CreateItem(); //产生Company类
 }
 class office和person同上
 
 弹出菜单变为
 treectrl::OnContextMenu(...)
 {
  treeItemor* ItemCreator = GetItemData(hSelItem);
  CCmdTarget *pCmd = ItemCreator->CreateItem();
  pCmd->SendCommand(WM_CONTEXTMENU, POINT);
 }
 
 呼！总算完了。最后请大家多提意见！