使用命名空间和本地变量 - 还是类？

Question

目前，我的游戏引擎中的模块都是按命名空间组织的。它们具有类的构造函数和析构函数类似的Open()和Close()函数，在游戏输入左侧时被调用。

这些模块的示例包括：物理管理器、实体管理器、I/O处理程序、渲染管理器。

现在，我开始觉得让所有模块的变量“散落”在那里，并通过链接器以全局方式导出不好。

将模块从命名空间重构为类会带来以下开销：

• 必须有一个全局控制器，允许不同模块之间的交互，通过提供对它们的实例的访问

• 模块之间的交互会多出一个函数调用和1-2个指针解除引用的额外开销

并且会有以下优点：

• 符合RAII规范
• 所有状态都可以打包到一个CState类中，其中包含模块的实例
• 有助于确保资源正确删除和分配

我的问题：

• 我应该考虑将我的引擎模块从命名空间重构为管理类吗？为什么（不）？

- Jarx

Answer 1

如果你有一组对对象集合进行操作的函数（方法），而这些函数不应该对集合外的其他函数可见，那么将这个集合的函数和对象放在一个类中似乎是很自然的选择。

“是否需要全局控制器？这听起来非常像“上帝对象”的反模式。即使你通常只有每个类的单个实例，它们也不必成为整个控制器类的成员，只要各个类中需要访问其他类的函数有一种获取该访问的方式即可。

我不确定你是如何得出这一点的。我认为这并不一定是必须的，但我建议你首先设计清晰，只有当性能不足时再进行优化。

- CB Bailey

Answer 2

如果涉及状态，则创建一个类以便您可以有多个状态实例是很好的。

然而，还有其他利弊：

• 命名空间是开放的，类是封闭的。 您可以更轻松地向命名空间添加内容。

• 您可以更轻松地在命名空间中对东西进行前向声明。 您不能对类中的东西进行前向声明-必须可见整个类声明。

• 这意味着命名空间更容易执行类似于PIMPL的操作。 您只需转发需要的函数即可。 对于类，您需要实际构建PIMPL-这很繁琐。

我想认为命名空间只是一个没有数据的类，或仅包含类静态数据的类。 即，命名空间类似于您无法拥有对象的类。 但是，不幸的是，C ++的许多限制阻止了这一点的字面真相。

• 有时我最终会得到一个命名空间和一个类。

- Krazy Glew