我的团队正在设计一组共同实现服务的 COM 对象。目前，设计不包括会话对象。"会话对象"是指客户端在使用服务之前创建并在使用服务后删除的对象。我试图说服团队我们需要这样一个会话对象，以便允许客户端控制服务内部资源的分配和释放。我正在寻找记录在案的设计模式来帮助我提出我的理由。
我知道许多COM接口不需要这样的会话对象。内部资源的任何初始化都是在创建第一个对象时完成的，无论该对象是什么对象，并且当服务器维护的最后一个对象被删除时(即，当其引用计数变为 0 时(，将释放这些资源。尽管这对客户端来说可能更简单，但问题是必须在创建第一个对象时支付初始化成本。如果客户端期望这是一个轻量级操作，并且大多数情况下是这样，则此初始化会导致不可预测和不希望的行为。
通过引入其生存期必须包装所有其他对象的生存期的会话对象，客户端可以控制初始化发生的时间，并确保初始化在使用会话管理的服务之前发生。(我意识到健壮的设计要求我的服务处理多个会话，并且在创建第一个会话对象并在删除最后一个会话对象时释放资源时支付初始化代价。
这种模式有名字吗？是否有任何记录在案的例子，我可以指出其他人来支持我的案件？我意识到我想做的与 RAII(资源分配是初始化(有关，但动机有点不同。
如果需要为此命名，请参阅注册表模式(EAA 的 P(、上下文对象模式(核心 J2EE 模式(和查找模式 (POSA3(。
在我的头顶上，在解析名字对象时，COM 中遵循非常相似的模式，即部分获取模式 (POSA3(，其中组合名字对象将其内容保存在可能对下一个名字对象有用的上下文中。
请参阅IMoniker范围内的IBindCtx。
上下文对象包含绑定选项、对必须保持活动状态的对象的引用、指向会话的正在运行的对象表的指针以及命名参数对象引用。 这些都用于 1( 将名称解析为名字对象和 2( 从名字对象获取实际对象。
通过将对象注册到绑定上下文，它们将在上下文期间保持活动状态，如果您以某种方式引用这些对象(通常是命名对象((假设一个表示实际 Office 文档的对象(，这可能会很有用。 这在效果上与您想要实现的效果类似，只是要获得实际对象，您通常需要命名它们，或者它们需要从绰号可以获取的其他对象访问。
通过设置对象参数(通常是具体的和/或未命名的实例(，它们可以更改名字对象的解析方式或用户交互发生(或不发生(以解析名字对象的方式。 在这方面，它不仅仅是一种优化，尽管当从空绑定上下文开始时，它通常这样使用。
如果您是预先设置名字对象的绑定参数的人，它将更类似于渴望获取模式。
这种方法的一个主要缺点是，就像只使用非类型化哈希表一样，很难理解可以在绑定上下文中放置什么，而绑定上下文将由名字对象实际使用。 因此，在您的情况下，我建议您尽可能使会话对象具有特定的类型化属性。
请注意，您尝试实现的目标也与缓存实例激活非常相似，而不是创建依赖项注入。 某些依赖注入框架还允许为某些接口或某些参数集返回相同的对象。 如果你已经在使用这样的框架，你可以避免重新发明轮子。