前面了解到了，用API直接搭建WINDOWS程序的过程。GUI程序的入口函数是WinMain()，在入口函数中用函数::CreateWindowEx()创建一个窗口，再注册并更新一个窗口，然后进入消息循环，当从用户或其它线程获得了一个消息，再调用指定的窗口函数，自定义的窗口函数在处理了特定的消息后，再将处理权交给系统默认的消息处理函数::DefWindowProc()。形式上是非常简单的，但事实上用起来并不是这么轻松的，当开发的系统变大时，用这样的方法搭程序，显然是很不够的，这个时候‘方法’会显得更加重要。我一直的观点是，搞理论的应该更注重‘结果’，而搞技术的应该更注重‘方法’。

MFC（Microsoft Fundation Classes）的设计就是出于这样的目的。它的本质就是对API的一个系统的封装，封装的过程是非常复杂的，但封闭的结果是非常实用的，用这样的方法搭建WINDOWS程序将会变得轻而易举。这就是‘方法’对技术的提高的一种表现吧。

总的看MFC，它由CObject从上往下展开（继承），主要的几个类有（这个时候我正拿着MFC体系图在看呢！），CCmdTarget支，它负责与消息处理有关的对象，包括CWinApp，用来搭建应用程序实例；CWnd，封闭了窗口的对象。这是最重要的两个类了，另外的还有CFile文件类，CDC设备环境类等。

使用的时候，用CWinApp派生CMyApp，重载virtual BOOL InitInstance();虚函数，意思是初始化实例。初始化的时候建立自己的窗口对象，从CWnd继承，如CMyWindow。在CMyApp::InitInstance()中定义一个CMyWindow对象作为成员，CMyWindow的生成函数中将设置窗口的特征，使用CreateEx()注册窗口，InitInstance()返回TRUE则表示进入消息循环。

这里还有个消息映射的问题，我们不愿意在一个消息处理函数中用switch(Message)，例一长条的case nMsgID:，这样的程序不好看，也不容易阅读，更不好维护，所以我们希望用一个简单的映射。MFC做的相对简单，完全由宏定义做的，消息是系统固定的，消息宏名大致是WM_开头，意为WindowsMessage，如WM_PAINT（一个通知窗口需要重画的消息），所以简单的可以用OnPaint()函数来处理，这样的函数就定义为由CWnd派生的子类CMyWindow的成员函数，于是需要做的映射就是从消息ID到函数句柄的映射。具体的实现可以查MFC宏定义，结果是用两个宏BEGIN_MESSAGE_MAP(CMyWnd,CWnd)，和END_MESSAGE_MAP()套在一起定义。在CMyWindow中使用DECLARE_MESSAGE_MAP()，再在它的实现文档中添上：
BEGIN_MESSAGE_MAP(CMyWindow,CWnd)
...
//映射的对应函数
END_MESSAGE_MAP()
致于为什么不用CMapPtrToPtr做一个映射，我觉得这里是为了考虑到效率，不用做太多的开销为这样一个简单的事情，简单是说‘形式’上的简单，做这样的映射完全是为了程序的可读可维护，其实也完全可以用switch()铺开做，只是管理的方法不同，而只是为了这样的形式的变化而做更多的开销，我觉得没必要。

这就是MFC为我们搭好的‘框架’，在这个框架下，我们可以快速的做一个应用程序。除此之外MFC没什么吸引人的地方。

但是好的‘方法’可能会决定一切！

评论