OOP设计:一个对象依赖于所有依赖项的存在

时间:2014-02-27 10:31:26

标签: c++ oop

只是抬头,我对这种设计理论没有接受过正规教育,所以如果我对一些概念一无所知,请耐心等待。我的所有推理都来自C ++的背景。我正在开发一个基于组件的系统,用于游戏引擎,这就是我提出的结构。

  • 有组件,只是数据。
  • 有节点,允许访问该数据。
  • 有些系统只在节点上运行。
  • 有实体,包含这些节点,组件,系统和其他实体。

非常简单,但我们只关注组件和节点,我有一套相当严格的指南。

  1. 节点可以提供对实体内组件集合的访问
  2. 一个节点依赖于所有其底层组件
  3. 的存在
  4. 组件可以独立于指向它的任何节点而存在。
  5. 系统只能访问节点
  6. 现在,任何这些节点和组件都可以随时销毁。我已经通过使用一组侵入式列表来维护一个跨节点迭代的非所有权方法,然后在销毁时自动从列表中删除自己,从而为节点实现了这一点。但现在我有一个关于组件的问题。在销毁某些组件时,还必须销毁依赖于该组件的所有节点。通常,对另一个被销毁时需要销毁的对象的简单修复是所有权,您只需将节点放置在组件中或在该组件析构函数中动态销毁它,但此处的节点可以引用多个不同的组件。当一个对象拥有多个所有者时,通常像智能指针这样的引用计数解决方案会为所有这些对象提供所有权,并在所有所有者被销毁时被销毁,但这次不是这种情况。我的一个大问题是,当我有一个只能存在 all 其依赖关系的对象时,以及在任何依赖关系被破坏时,我在拥有权方面做了什么?在破坏那个依赖对象时。

    示例:

    Red are components needed for the existence of the second node

    What it looks like after either component it depends on is destroyed

    显然,有多个不洁的解决方案,包括弱指针,手动删除以及对物体存在的大量检查,但是就像所有问题一样,我想知道这是否可以通过设计单独安全地实现。同样,如果这是一个非常简单或众所周知的概念,请指出我正确的方向。

    @Jorgen G Valley - 所有对象确实归实体所有,因为所有对象都在销毁包含实体时被销毁,但节点,组件,系统和实体应该是能够动态地随时添加或删除。这是一个例子。从世界实体开始,该实体包含一个网格和两个向量的实体。这两个向量是独立更新的,但是假设你想要将它们组合在一起,你只需添加一个节点,指定一个向量作为父对象,将任意数量的向量作为子对象。将节点添加到实体将其置于非拥有列表中,允许先前存在的“父”系统迭代所有“父”节点并在每个父节点上执行功能。不显示对象只涉及删除节点,但是矢量和网格应该仍然存在。假设您想要销毁该向量并保留在网格上以便在另一个模型中使用,那么该向量的销毁也应该销毁父节点,因为它不再引用有效的向量。

    以下是一些视觉效果:

    这是上述情况的一个例子。 here

    现在这里是删除父节点的示例。 here

    注意组件保持不变,因为它可以在其他节点中使用,例如在此示例中,渲染节点正在使用它。节点的破坏关闭了父系统使用的侵入列表中的间隙,这意味着父系统只管理具有父节点的任何其他实体。

    现在这里是一个删除矢量分量的例子。 here

    在这种情况下,还必须删除依赖于该向量的所有节点,包括父节点和渲染节点。破坏弥补了各个侵入列表中的空白,系统继续存在。希望这有助于说明我想要实现的设计。

1 个答案:

答案 0 :(得分:0)

我认为你的事情比你需要的更复杂。您说节点和组件可以随时销毁。这是真的吗?

在您的文本中,您将实体描述为所有者,因为您说它包含组件,节点和系统。

我对此的处理方法是,只有拥有它的实体被销毁时才会销毁一个组件。这意味着节点,组件和系统不需要为破坏而烦恼。它由拥有对象即实体完成。

编辑:如果您遇到可以销毁组件,节点或系统而没有要覆盖的覆盖实体的情况,我很想听一个例子。这本身就是一个非常有趣的问题。 :)