包容和聚合是COM的两种重用模型，它们的思路基本一致，只是在实现方法上有所不同，下面简要总结一下实现方法：

1.包容：

假定我们已经实现了一个COM对象，不妨称它为对象A，它实现了接口ISomeIntf，不久之后，考虑到新的需要，我们要实现一个新的COM对象，称它为B，它既要实现接口ISomeIntf，也要实现接口IOtherIntf，而且，ISomeIntf接口所提供的服务与对象A所提供的服务基本一致，于是，我们考虑在实现对象B的过程中重用对象A的功能，只需要实现新添加的功能就可以完成对象B的开发工作。

最简单的想法就是在实现对象B的接口ISomeIntf时调用对象A的相应成员函数，对于对象A来说，它只是当作一个普通的COM对象，而对于对象B来说，虽然它本身是一个COM对象，但它同时也是对象A的客户，因为它调用对象A的功能服务。对象B不再重复实现对象A已经实现的功能，而是调用对象A的服务来提供对外的功能服务，对于对象B的客户来说，它根本不知道对象A的存在，可以说它是最大的受益者，因为它得到了全面的功能服务。这样的情形，我们称为对象B包容对象A，或者对象A被对象B包容，可以用下图表示这种包容关系。

包容的模型在实际使用过程可以非常灵活，对象B的成员函数在调用对象A的接口成员之前或者调用返回之后也可以进行其他一些操作，因此，对象B的ISomeIntf接口提供的功能可以超过对象A的接口功能，返回结果也可以不一致。更有甚者，对象B的接口与对象A的接口不一定相同，对象B和对象A可以只是一个客户和服务程序的关系而客户程序所看到的只是对象B所暴露出来的接口，对象A的创建和释放完全在对象B内部进行。一般来说，对象A的生存期包含在对象B的生存期之内。比较简单的做法是在对象B被构造时，同时创建对象A，并保存好对象A的接口指针，以便在对象B的成员函数中使用；当对象B被释放时，它先把对象A释放掉，这样可以完成对象B对对象A的嵌套使用，形成包容对象模型。如果要优化程序并提高资源利用率的话，赐教对象B可以在需要的时候才创建对象A，在不需要的时候及时释放掉。

2.聚合：

然后我们再看看对象聚合的情形。假定我们要实现一个对象B，它支持两个接口ISomeIntf和IOtherIntf，同时我们发现对象B所提供的ISomeIntf功能在另一个对象A中已经实现，而且不需要修改就可以满足对象B的要求。如果采用对象包容模型，则对象B要实现两个接口，并且在接口ISomeIntf的成员函数中调用对象A的相应函数，但现在我们采用聚合的模型来实现对象B。对象B本身并不实现接口ISomeIntf，它只实现IOtherIntf接口，但它也能提供接口ISomeIntf的功能，当对象B的客户请求接口ISomeIntf时，对象B把对象A的ISomeIntf接口指针暴露给客户程序，因此，客户程序调用ISomeIntf时直接与对象A进行交互，但客户并没有感觉到在与对象A进行交互，它仍觉得自己是在与对象B进行交互。聚合模型如下图所示。

在聚合模型中，被聚合的对象A虽然直接向对象B的客户程序提供功能服务，但它的生存期仍受对象B控制，而且其他的一些行为也受对象B控制，包括内部状态初始化、获取数据等待，对象B借对象A向客户程序提供ISomeIntf接口服务。实现聚合的着急在于对象B的QurayInterface成员函数，当客户程序向对象B请求ISomeIntf接口时，对象B的QuaryInterface函数把对象A的ISomeIntf接口指针放到输出参数中，客户程序就获得了对象A的ISomeIntf接口指针，可以直接调用接口成员函数了。

但事情并没有这么简单，当月客户程序通过ISomeIntf::QuaryInterface函数又请求其他的接口指针时，问题就复杂了，因为对象A并不知道对象B实现了什么样的接口，而据COM规范，客户程序从对象B的任一个接口可以获取其他的任务接口指针。而且，在正常情况下，客户程序调用对象A的ISomeIntf::QuaryInterface函数请求IUnknown接口指针获得的是对象A的IUnknown接口指针，而客户程序调用对象B的IOtherIntf::QuaryInterface函数请求IUnknown接口指针获得的是对象B的IUnkown接口指针获得的是对象B的IUnknown接口指针，而COM规范要求对象的IUnknown接口指针必须唯一。因为，为了使用聚合能顺利实现，对象A也必须能够适应在被聚合的情况下进行特殊的处理，尤其接口的QuaryInterface成员函数，在被聚合的情况下，当客户请求它所不支持的接口或者请求IUnkown接口时，它必须把控制交给外部对象，由外部对象决定客户程序的请求结果。

聚合涉及到聚合对象和被聚合对象双方的协作，并不是每个对象都能够支持聚合特性，但聚合体现了组件软件真正意义上的重用。而包容的重用性完全建立在客户/服务器模型相对性的基础上，实际上也就是客户程序和组件程序的嵌套关系。这是包容和聚合本质的不同。

当组件系统经过一定时间的发展后，很重要的工作是组件系统的升级更新或者系统扩展，包括接口的扩展。在实现新的接口或开发新的组件对象时，就充分考虑重用已有的组件软件。根据包容和聚合的不同结构，我们在选择重用模型时，可以依据这样的原则：在一个组件对象在行为上更类似于另一个组件对象的客户，并且它要调用第二个对象的某些对象接口的情况下，比较适合用包容模型，第一个对象包容第二个；如果一个现成的组件对象所实现的接口与将要实现的对象的接口的行为完全完全一致，则采用聚合模型更为合适，当然前提条件是现有的组件对象必须支持聚合特性。

聚合和包容是COM对象的两种重用模型，它们互相并不矛盾，因此，我们也可以在一个对象中同时使用两种模型，有的接口通过包容实现，有的接口通过聚合实现。但现在使用这两种模型之前，尤其在使用聚合模型之前，需要对模型的细节有清晰的了解，这样才能够真正把已有的组件软件重用起来。