编写可复用性更好的C++代码:Band对象和COMToys(9)

核心提示： 下载COMToys的源代码以后可以用六种方式编译：与MFC静态链接的静态库（static library），与MFC动态链接的静态库（static library），编写可复用性更好的C++代码:Band对象和COMToys(9)(4)，或者与MFC动态链接（扩展DLL）的DLL，用Deb

下载COMToys的源代码以后可以用六种方式编译：与MFC静态链接的静态库（static library），与MFC动态链接的静态库（static library），或者与MFC动态链接（扩展DLL）的DLL，用Debug和Release模式编译它们从而形成六个版本。　

存在的问题

哪个系统会没有问题呢？包括COMToys在内还有很多地方需要完善。我只写了Band对象所需要的那一部分。因此，像CTPersistStream 和 CTPersistFile并未做任何实质性的事情；它们只有一个修改标志。像微软在bug文档中惯用的伎俩一样：当你不能解决某个bug的时候，就把它当做一个特性。把它说成：“这是设计行为云云......”

COMToys的另一个令人讨厌的是宏调试问题——有时你无法在调试器中跟踪进去。幸好我到哪都不喜欢使用调试器，而是用自己的跟踪方法。　

COMToys和MFC　

在进行总结之前，关于COMToys和MFC之间的关系，我想再多罗嗦几句。COMToys似乎很依赖MFC。我对此不以为然，因为我喜欢MFC并总是乐于使用它。但有些人觉得MFC是负担和累赘。我觉得不要陷入MFC和ATL之间的争论，但我必须指出，从本质上讲，COMToys将接口融于实体类的方法是独立于MFC的，也就是说在这一点上它不依赖MFC。　

当我编写COMToys的时候，我仔细地注意了在哪里需要MFC，哪里不需要它。因此，CTOleWindow，CTDockingWindow和CTInputObject使用了句柄（HWND，HACCEL）来代替CWnd*之类的MFC对象，因为它们不需要MFC来打包任何东西。另一方面，CTMfcContextMenu需要CMenu和CCmdTarget，因为它完成所有的命令例程。同样，CTMfcModule调用MFC来实现标准的DLL入口。通常在设计与MFC有关的类时，我在名字中都包含有“Mfc”。