公开对象管理器对象的可接受方法？

Acceptable way to expose an object manager's objects?

本文关键字：可接受 方法 对象 对象管理器      更新时间：2023-10-16

场景是，我正在使用负责加载和管理纹理的TextureManager类构建游戏。实现 IVisibleGameObject 的游戏对象需要从 TextureManager 指向纹理的指针/引用。

纹理管理器是使用std::map<std::string, boost::shared_ptr<Texture> >实现的，用于在内部保存其对象。

我

不确定我应该如何实际暴露纹理，并想到了几种可能性，每种可能性都有自己的缺点：

1） const Texture& GetTex(std::string textureKey)

我觉得会很理想，但我想通过返回 NULL 来表明在地图中找不到纹理。（第二次猜测自己...这合适吗？

2） shared_ptr<const Texture> GetTex(std::string textureKey)

在这里我可以返回一个空shared_ptr，但我对它现在是一个共享对象的暗示感到不舒服。纹理管理器是对象的所有者，毕竟是管理器。但是，考虑到 IVisibleGameObject 包含指向返回纹理的引用/指针并依赖于它的存在才能正常运行，它不也是对象的所有者吗，也许共享所有权是合适的？

3） const Texture* GetTex(stD::string textureKey)

显然，这是错误的答案。

希望有人为我澄清这一点，也许有些事情我没有考虑过。

我会坚持使用标准的库习语，简单地公开find和end。然后，您可以非常高效：

auto it = my_objects.find("foo");
if (it == my_objects.end())
{
    // handle "not found"
}
else
{
    it->second->do_magic();
}

标准库已经有一个完全可用的通用习惯用法，用于处理集合和指示元素的存在或不存在，以及组合插入-新或返回-现有的语义。为什么要重新发明轮子...

我要做的是让纹理管理器保留指向每个纹理的单个共享指针，并使游戏对象保留弱指针。这样，您可以确保在退出时正确释放所有内容（保证没有周期）。

相关文章：