基于MFC的插件系统开发.docVIP

基于MFC的插件系统开发 解剖MFC程序 现代工业的特征之一就是分工，一旦能够分工，就会出现“术业有专攻”的局面。建筑业需要钢材，冶金需要矿石、采矿需要设备，……，由此带来生机勃勃的现代文明社会。我们很难想象：建造一座楼房的时候，需要的钢材自己炼、需要的砖瓦自己烧、需要的电梯自己造，会是一种什么感觉？MFC编程可能就是这样，如果MFC程序是一座楼，今天的MFC程序员必须亲历亲为，需要亲自盖起楼的主体结构、形成层次、……、装修房间、完成布线等等一系列工作。因此，我们有必要对现在的MFC程序进行一次外科解剖手术，使MFC程序的构造能够实现分工。 我们从剖析一个典型的MFC多文档程序开始，典型的MFC程序，通常由一个文档框架主窗口（CMainFrame）以及一组“文档”模板构成。程序的形态取决于CMainFrame，内容取决于其包含的文档模板。在代码结构上，主窗口、文档、文档框架窗口（CChildFrame）、View等类型对象耦合在一起形成了一个通常意义下的MFC程序，对象耦合的过程，被MFC框架巧妙地封装了。因此，多少年来绝大多数场合下人们看到的是一个近乎“永恒”的代码结构： CMultiDocTemplate* pDocTemplate; pDocTemplate = new CMultiDocTemplate( IDR_MsdnPluginSamplTYPE1, RUNTIME_CLASS(CSampleDoc1), RUNTIME_CLASS(CChildFrame1), RUNTIME_CLASS(CUserCtrlView)); if (!pDocTemplate) return FALSE; AddDocTemplate(pDocTemplate); pDocTemplate = new CMultiDocTemplate( IDR_MsdnPluginSamplTYPE2, RUNTIME_CLASS(CSampleDoc2), RUNTIME_CLASS(CChildFrame2), RUNTIME_CLASS(CUserCtrlView)); if (!pDocTemplate) return FALSE; AddDocTemplate(pDocTemplate); ... pDocTemplate = new CMultiDocTemplate( IDR_MsdnPluginSamplTYPEn, RUNTIME_CLASS(CSampleDocn), RUNTIME_CLASS(CChildFramen), RUNTIME_CLASS(CUserCtrlView)); if (!pDocTemplate) return FALSE; AddDocTemplate(pDocTemplate); CMainFrame* pMainFrame = new CMainFrame; if (!pMainFrame || !pMainFrame-LoadFrame(IDR_MAINFRAME)) return FALSE; m_pMainWnd = pMainFrame; pMainFrame-ShowWindow(m_nCmdShow); pMainFrame-UpdateWindow(); 只要你用过MFC，你一定接触过上述代码，从中你会感受到一张沧桑的面孔。这段代码贴切地显示出MFC框架的呆板、僵化。深入了解了这些代码背后发生的故事，你会发现解开MFC框架臃肿、僵化的玄机就在这里。从上面给出的代码中可以看出，MFC程序在初始化阶段通过AddDocTemplate(pDocTemplate);填充了一个文档模板队列。完成文档队列填充后的工作就是实例化一个主窗口，然后创建该窗口并显示出来。这个初始化过程许多年来一直在以相同的模式重复着，就像一个物理规律，几乎时时刻刻地发生在MFC的世界里。每增加一个文档模板，就需要在程序中增加一个文档类、一个文档框架窗口和一个或多个视图类，然后在程序初始化阶段重新构造一个文档模板类，将其填充到文档模板队列中……你的程序至少需要增加3个类。如果要构造支持5个文档类型的MFC程序，得到的程序结构将十分丰满，因为保守估计该程序也得包含15个以上的C++类。对初学者而言，会因此而极大地增强信心，因为他终于写出很大的C++程序了；然而对一个大型的综合程序而言却是一个噩梦，一个系统如果要求100个用户视图、20个文档类型，用MFC框架开发就是件十分“恐怖”的事情。由此我们看到“文档模板队列”是基于文档的MFC程序结构臃肿之症结所在。 然而，换个角度看基于文档的MFC程序的结构就很简单：无外乎一个文档模板队列，以及一个支撑文档显