现在，我的游戏引擎中的模块被组织为命名空间。它们具有 Open() 和 Close() 函数，其作用类似于类的构造函数和析构函数，并在游戏向左进入时调用。
这些模块的示例是：物理管理器、实体管理器、I/O 处理程序、渲染管理器。
现在，我开始认为让模块的所有变量“躺在”周围并通过链接器全局导出是不好的。
将模块从命名空间重构为类会带来以下开销：
必须有一个全局控制器，通过证明可以访问它们的实例，允许不同模块之间的交互
模块之间的交互会产生函数调用和 1-2 指针取消引用的额外开销
还有以下优点：
我的问题：
【问题讨论】：
标签： c++ design-patterns namespaces game-engine
如果您有一组函数（方法）对一组对象进行操作，而这些对象的集合对该集合之外的其他函数不可见，那么将该函数和对象的集合放在一个类中似乎很自然。
必须有一个全局控制器，允许不同模块之间的交互，通过证明对它们的实例的访问
是否必须有一个全局控制器？这听起来很像“上帝对象”反模式。即使您通常只有每个类的单个实例，它们也不必都是整个控制器类的成员，只要需要访问其他类的各种类中的函数有办法获取访问权限。
模块之间的交互会产生函数调用和 1-2 指针解引用的额外开销
我不确定你是如何解决这个问题的。我不认为必须是这种情况，但我建议您首先进行清晰设计，并且仅在性能不足时才进行优化。
【讨论】：
如果涉及到状态，那么创建一个类以便拥有多个状态实例是很好的。
但是，也有其他优点和缺点：
命名空间是开放的，类是封闭的。您可以更轻松地向命名空间添加内容。
您可以更轻松地对命名空间中的内容进行前向声明。您不能对类中的内容进行前向声明 - 整个类声明必须是可见的。
这意味着命名空间更容易在道德上与 PIMPL 等效。您只需向前声明所需的函数。使用一个类，您需要实际构建一个 PIMPL - 这很乏味。
我想认为命名空间只是一个没有数据的类，或者一个只包含类静态数据的类。 IE。命名空间类似于您不能拥有对象的类。但是，不幸的是，C++ 的许多限制阻止了这一点。
【讨论】：