模块复用——c＋＋类、dll和com

    这篇文章只是对c＋＋、dll和com的泛泛而谈，更为详细的内容请参考《com本质论》，这篇文章也算是《com本质论》第一章的读书笔记或总结。如有不对之处，希望大家批评指正。

在windows下使用c＋＋编写代码的人代码复用的常用方式大概就是c＋＋类、dll和com
一、c＋＋代码重用的缺陷
    以前的c＋＋开发人员复用代码的方式大概就是获得一套.h和.cpp文件，然后把这些文件加入到自己的工程中编译、连接，最后生成exe文件。这种代码级的复用方式存以下的问题
1、c＋＋程序员通常根据自己的需要修改别人提供的代码。开发者要使用代码，通常会根据源代码来理解代码的意图。更为老火的是，还要理解代码提供者的思路和编码风格
2、c＋＋代码级复用导致了硬盘和内存空间的浪费
    假如机器上有n个软件使用了类CA，在每个软件的存储空间中都会有class CA的一份编译生成的代码，在这n个软件同时执行时，会占用n×sizeof(CA)大小的内存空间
3、软件一经发布，除非重新编译整个软件，否则无法修改
    假如发现了类CA存在一个bug，要修改CA的实现来修复这个bug，那么就只有重新编译整个软件。软件根本就不具备2进制的模块化特性。
二、如何解决以上问题————dll的引入
    在window中，一个很好的技术就是动态链接库（dll），有了dll技术，客户可共享该dll的代码，这样在用户机器上无论有多少个软件使用该dll，都会只有一份该dll的拷贝。而dll提供给开发者的也只是.h文件，隐藏了代码的实现细节。
三、dll复用存在的问题
1、编译器、连接器的不兼容问题
    为了支持重载，c＋＋编译器任意修改函数名（名字改编，感兴趣的可参考《深入探索c＋＋对象模型第4章——function语意学》），而且每个c＋＋编译器修改函数名的方法通常都不相同。这个问题的一个解决方案是将函数声明extern “C”链接指示符,这样做的一个缺陷是：不能用extern “C”声明成员函数。另一个解决方案是修改DEF文件，这样可保证所有的编译器导出相同的函数名，可保证dll在链接时的兼容。但这还不能保证2进制结构的兼容性，由于c＋＋标准并未规定程序运行时的状态，每个编译器可能有自己的一套处理方式，比如在做异常处理时，一个编译器抛出的异常，在另一个编译器中可能不能扑获到
2、dll致命的弱点——版本冲突问题
    dll的版本问题是臭名昭著的。解决版本冲突问题的经典方法是重命名dll文件名（这也是mfc的解决方案，mfc42d….mfc42ud等）。
四、祭出法宝，面向对象的原则——接口和实现的分离
    dll版本问题的关键在于c＋＋的编译模型和对象之间的紧密耦合关系，c＋＋编译模型要求客户需要了解对象的内存布局，以便为对象分配内存。该问题的根本解决之道是分离接口和实现。把实现封装在dll的内部，客户通过接口来访问实现。这样，在客户代码中不会包含复用模块的实现部分。
五、com的解决方案
    com是严格分离接口和实现的，客户只能通过接口来访问组件的实现。保证了不把任何实现细节暴露给客户。在客户使用组件分配内存时，也只有com接口中的vptr指针。Com使用接口继承的方式分离接口和实现。而大多数编译器对vptr和vtbl生成的内存布局是一致的。这样就解决了编译器之间的不兼容关系。

    当然，com的用处还很多。Com技术也很复杂，我也不想多说 了，一是因为我懒，二是因为我水平还很菜，《com本质论》是一本好书。学com一定要看。

    最后，想谈谈目前的软件开发环境。由于.net的推出，很多人在问现在学习com还是否值得。看看目前的软件，ie，office，msn包括.net的核心，哪个不是用com搭建起来的，而且我们学习com，关键是它的设计思想，知其然而知其所以然，了解了其背后的设计动机，用com还是用dll都是一样的了，如果只是用用，不学也罢. 。dll只是com的一种发布形式而已。即使在其他平台，这种思想也是很有用的，在com中体现的是OO的思想——接口和实现的分离、开－闭原则、针对接口编程，甚至强迫你使用某些设计模式。我认为，这就是学习com的价值。。而且，研究atl的源码中对com的实现，也能学到一些实用技术和设计模式。而这些东西是永远不会过时的。。技术是在不断演化的，但新技术也是旧技术积累产生的。Wtl之父也建议在学习.net前学学com。实际上，在window平台上，com永远有它的一席之地。。。。