所谓子类化，也就是因为某种需求，对一个windows窗口(当然这里的窗口可以是控件、Dialog等)用自己的窗口函数，代替原有的窗口函数）
再看看别人的解释：
所谓窗口子类化，实际上就是改变窗口内存块中的有关参数。由于这种修改只涉及到一个窗口的内存块，因此它不会影响到属于同一窗口类的其它窗口的功能和表现（IDàHWNDàCWnd）。窗口子类化中最常见的是修改窗口内存块中的窗口函数地址（lpfnWndProc），使其指向一个新的窗口函数，从而改变原窗口函数的处理方法，做出特定功能适应。
在实际开发中，有些情况标准控件的标准过程是无能为力的。比如：在我们的应用中要求一个EDIT控件接收老师对学生的评价，评价分三个等级A、B、C（不要对我说你想用ComboBox实现），这就要求在EDIT中禁止对其它字母、数字的输入操作，怎么办？EDIT控件本身没有提供这种机制，采用子类化可以很好的解决这类问题。
我们知道，每一个Windows窗口（这里指EDIT）都有一个窗口处理函数负责对消息的处理，子类化通常就是用我们自己的消息处理函数来替代窗口原有的、标准的处理函数。当然我们自己的窗口处理过程只是关心那些特定的消息（在这里是WM_CHAR），而其它消息将发给原来的窗口函数做默认处理。
下文来自与百度文库中的一篇文章：http://wenku.baidu.com/view/a4131b94dd88d0d233d46afd.html
走出MFC子类化的迷宫:子类化，SUBCLASSWINDOW ,MFC消息机制
---(摘自CSDN论坛)
许多Windows程序员都是跳过SDK直接进行RAD开发工具[或VC，我想VC应不属于RAD]的学习，有些人可能对子类化机制比较陌生。
我们先看看什么是Windows的子类化。Windows给我们或是说给它自己定义了许多丰富的通用控件，如：Edit、ComboBox 、ListBox……等，这些控件功能丰富，能为我们开发工作带来极大方面，试想：我们单单是自己实现一个EDIT控件是多么的艰难！但是，在实际开发中还是有些情况这些标准控件也无能为力，比如：在我们的应用中要求一个EDIT得到老师对学生的评价A、B、C[不要对我说你想用ComboBox实现J]，这时，要求在Edit中禁止对其它字母、数字的输入操作，怎么办？EDIT控件本身没有提供这种机制，我们就可以采用子类化很好的解决这类问题。
我们知道，每一个Windows窗口[这里是EDIT]都有一个窗口处理函数负责对消息处理，子类化的办法就是用我们自己的消息处理函数来替代窗口原有的、标准的处理函数。当然我们自己的窗口处理函数只是关心那些特定的消息[在这里当然是WM_CHAR了]，而其它消息，再发给原来的窗口函数处理。在SDK中的实现方法是调用函数SetWindowLong ：
（自己注：所谓子类化，也就是因为某种需求，对一个windows窗口(当然这里的窗口可以是控件、Dialog等)用自己的窗口函数，代替原有的窗口函数）
其中AfxGetAfxWndProc()是我们自己的窗口处理函数，在其中处理过我们感兴趣的消息后就可能通过返回的原窗口处理函数指针oldWndProc来把其它消息按标准方法处理掉，具体做法请查阅相关资料。
但到了MFC“时代”，一切都被包装起来了，原来的窗口类注册、窗口函数都不见了[或是说隐身了]，我想对于那些“刨根问底”的程序员有兴趣了解在MFC中的子类化机制，本人就自己做的一点“探索”作出总结，希望能给大家点启示。
我们先用MFC实现我上面提到的要求：一个只能输入A，B，C的EDIT控件。
启动时界面如下：
输入时就只能输入A、B、C，并且只允许输入一个字母。
实现方法：
先派生一个自己的类CsuperEdit，Ctrl + W后，在其中处理WM_CHAR，然后再编辑这个消息处理函数：
然后再给我们Cprog1Dlg类中加入一个数据成员CsuperEdit m_edit，在CProg1Dlg::OnInitDialog()中加入：
m_edit.SubclassDlgItem(IDC_EDIT1,this);
m_edit.SetWindowText("<请输入A、B、C>");
并处理EDIT向DIALOG发送的通知消息：EN_SETFOCUS：
（PP注：注意，以上操作是现在对话框资源上拖入一个CEdit控件，CSuperEdit类与这个控件没有直接关系，不是通过选中控件然后Add Class添加的）
OK，一切搞定！和SDK的子类化方法比起来，这是多么的容易！
我们看看MFC背着我们到底做了什么！这里主要解决两个容易让初学者比较疑惑的问题：
1、 m_edit只是我们定义的一个C++类对象，为什么通过它调用其成员函数SetWindowText便可以控制我们程序中资源编号为：IDC_EDIT1的控件？
2、 CSuperEdit类为什么可以处理WM_CHAR消息？
大家都知道，控制Windows窗口、控件、资源……都是通过它们的句柄来实现，如 HHANDLE、HWND、HDC都是句柄，它表现为一个32位长整形数据，存放于Windows中的特定区域，我们可以把它理解为指向我们想控制的窗口、控件、资源的索引，有了它，我们就可以控制我们想要控制的对象。
这里你可以想到为什么多数API函数都有一个参数HWND hwnd了吧！
我们的C++变量m_edit（pp注：m_edit只是个C++对象，Windows系统是“不认识”的，或者说，是无法直接操作的）要想控制IDC_EDIT1，也要通过它的句柄，但这又是如何实现的呢？您可能注意到了m_edit.SubclassDlgItem(IDC_EDIT1,this);一句，对了，这就是关键所在！
在此处F9设置断点，F5之后，程序到达此处，F11跟入SubclassDlgItem函数：
代码开始时对传入的父窗口做些检查，然后就是
这是关键的代码，先用hWndControl得到我们IDC_EDIT1控件的句柄，然后调用 SubclassWindow函数，这个函数是实现的关键，我们来看一下它做了什么：
函数Attach内部如下：
这里要说明的是pMap->SetPermanent(m_hWnd = hWndNew, this);一句，它把我们IDC_EDIT1的句柄赋值给类CsuperEdit的数据成员m_hWnd [别忘了我们的CsuperEdit类是派生于Cedit的]，大家可能现在已经隐约的明白了些什么，不错，在m_edit.SetWindowText("<请输入A、B、C>");中正是通过这个数据成员m_hWnd实现对IDC_EDIT1控制的：
其它CEdit类的函数也都是围绕 “m_hWnd + API函数” 进行包装的。
而我们常用的DDX_Control方法说到底也是调用SubclassWindow。
怎么样？第一个问题的来龙去脉搞明白了吧？
现在看看第二个问题：CSuperEdit类为什么可以处理WM_CHAR消息？
可能有的朋友现在疑惑，虽然通过句柄实现了m_edit对IDC_EDIT的控制，但发送给它的消息照样跑到EDIT的标准处理函数中，对WM_CHAR的处理是如何实现的呢？
如果消息照样跑到EDIT的标准处理函数中，那当然是不能处理了！不知您有没有看到在上面的SubclassWindow函数中有这么一小段我加了重点标示：
再和我们开始讲到的SDK中子类化机制联系起来，明白了吧？MFC在这里神不知鬼不觉的搞起偷天换日的勾当！
这个AfxGetAfxWndProc()函数是这样的：
读过侯捷先生《深入浅出MFC》的朋友不知还是否记得MFC的命令路由机制正是以这个函数为起点的！
这样当程序收到发给Edit的WM_CHAR时，本应调用EDIT标准窗口处理函数，现在被改为调用LRESULT CALLBACK AfxWndProc(HWND hWnd, UINT nMsg, WPARAM wParam, LPARAM lParam)了，然后WM_CHAR消息进行一系列的流窜，最终成功到达我们的处理函数CSuperEdit::OnChar(UINT nChar, UINT nRepCnt, UINT nFlags)，至于是如何流窜的、怎么到达的请参考《深入浅出MFC》[如果您的书是繁体电子版，请从566页读起]。
终于，我们走出了MFC子类化的迷宫。
pp总结：
其实，
上面的例子，并没有用到DDX_Control。
其实在VC中，如果想自己定义控件类，可以不用自己动手做m_edit.SubclassDlgItem(IDC_EDIT1,this);这个子类化工作。在CEdit资源上右键Add Variable，VC帮助我们做了
void CtedDlg::DoDataExchange(CDataExchange* pDX)
{
CDialog::DoDataExchange(pDX);
DDX_Control(pDX, IDC_EDIT1, m_Edit);
}
跟踪一下DDX_Control的源码：
void AFXAPI DDX_Control(CDataExchange* pDX, int nIDC, CWnd& rControl)
{
if ((rControl.m_hWnd == NULL) && (rControl.GetControlUnknown() == NULL)) // not subclassed yet
{
ASSERT(!pDX->m_bSaveAndValidate);
pDX->PrepareCtrl(nIDC);
HWND hWndCtrl;
pDX->m_pDlgWnd->GetDlgItem(nIDC, &hWndCtrl);
if ((hWndCtrl != NULL) && !rControl.SubclassWindow(hWndCtrl))
{
ASSERT(FALSE); // possibly trying to subclass twice?
AfxThrowNotSupportedException();
}
#ifndef _AFX_NO_OCC_SUPPORT
else
{
if (hWndCtrl == NULL)
{
if (pDX->m_pDlgWnd->GetOleControlSite(nIDC) != NULL)
{
rControl.AttachControlSite(pDX->m_pDlgWnd, nIDC);
}
}
else
{
// If the control has reparented itself (e.g., invisible control),
// make sure that the CWnd gets properly wired to its control site.
if (pDX->m_pDlgWnd->m_hWnd != ::GetParent(rControl.m_hWnd))
rControl.AttachControlSite(pDX->m_pDlgWnd);
}
}
#endif //!_AFX_NO_OCC_SUPPORT
}
}
VC已经替我们做了工作。当然例子中，只是帮助我们理解