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

核心提示： 前面所讨论的MyBands程序有两层结构，底层是框架BandObj，编写可复用性更好的C++代码:Band对象和COMToys(5)(3)，上面是应用MyBands，这两层结构是出于示范目的人为创建的，）自从有了COM以后，MFC越来越成问题：其嵌套类的使用完全失去了个性，在实际编程中，我

前面所讨论的MyBands程序有两层结构，底层是框架BandObj，上面是应用MyBands。这两层结构是出于示范目的人为创建的。在实际编程中，我用的是三层结构来建立BandObj框架，如图十六所示。此结构的基础由COMToys提供。从图中可以看出，只有把COMToys移走之后才能聚焦在Band对象上。现在就让我们来揭示这个系统吧。

图十六 MyBands的体系结构

我在设计MyBands/BandObj/COMToys的时候，必须做出一个今天许多程序员都要面对的决定：即使用什么编程系统来编写COM？是用ATL?，MFC?，COM+?，或者以上的都不用?尽管我常常喜欢卖弄一下自己，但是从来不拒绝使用别人做好的东西，只要它能工作并且容易使用。所以我考虑ATL和MFC两者都用。

ATL口碑很好并且易于使用，但谁能搞懂所有的关于它的术语和那些尖括弧呢？你真知道ATL产生了多少代码吗？如果这些代码这么适于在模板中通用，那为什么不使用一个简单的类或子例程取而代之呢？一点都没错，模板能将很多东西参数化，这一特性当然很棒。但我只想开一个杂货店，没有必要也不需要借助航天飞机。更重要的是，ATL缺乏图形用户界面的支持，而像Band对象这样的外壳扩展需要GUI支持。话又说回来，ATL的简单易用，多继承模型及智能指针的诱惑让人无法拒绝，就象前面文章中曾用到的ATL的注册器，它让我爱不释手。

MFC又怎么样呢？它的GUI的诱惑力是不可抗拒的。即便你不需要文档/视图结构，它还有命令处理例程和ON_COMMAND_UPDATE_UI处理器——此乃任何UI对象之根本。但只要涉及到COM，MFC便逊色多多。大多数人都是担心它那大象般体积的DLL，但依我之见，那没什么了不起，不错，MFC42.DLL的确肥大，但是没有了它，Windows能转起来吗？它是OS的一部分，Windows中到处到有它的影子。（事实上，看一下Windows 98 的CAB文件就知道，这个肥大的东西就藏在在win98_62.cab文件中，所以说它是Windows的一部分。）自从有了COM以后，MFC越来越成问题：其嵌套类的使用完全失去了个性。稍后还要详细描述这方面的问题。