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