State with namespaces and locals
Right now, the modules in my game engine are organized as namespaces. They have Open() and Close() functions which act similar to constructors and destructors of classes, and are called when the game is entered left.
Examples for these modules are: The physics manager, entity manager, I/O handler, rendering manager.
Now, I'm beginning to think that it is bad to have all the variables of the modules "lying" around and being exported globally via the linker.
Refactoring the modules from namespaces into classes would bring the following overhead:
There would have to be a global controller which allows interaction between the different modules, by proving access to their instances
Interaction between modules would get the extra overhead of a function call and 1-2 pointer dereferences
And the following advantages:
My questions:
If you have a set of functions (methods) that operate on a collection of objects that shouldn't be visible to other functions outside of that set then it would seem natural to put that collection of functions and objects in a class.
There would have to be a global controller which allows interaction between the different modules, by proving access to their instances
Does there have to be a global controller? This sounds very much like the "God object" anti-pattern. Even if you only usually have a single instance of each of your classes, they don't all have to be a member of an overall controller class so long as the functions in the various classes that need access to other classes have a way of getting that access.
Interaction between modules would get the extra overhead of a function call and 1-2 pointer dereferences
I'm not sure how you've worked this out. I don't believe that this has to be the case but I would recommend that you design for clarity first and the optimize only if the performance isn't adequate.
If there is state involved, then creating a class so that you can have multiple instances of the state is good.
However, there are other pros and cons:
namespaces are open, classes are closed. You can add stuff to a namespace more easily.
You can make forward declarations of stuff in namespaces more easily. You can't do forward declarations of stuff in a class - the whole class declaration must be visible.
this means that namespaces are a bit easier to do the moral equivalent of PIMPL in. You can just forward declare the functions you need. With a class, you need to actually build a PIMPL - which is tedious.
I would like to think that a namespace is just a class that has no data, or a class that only contains class static data. Ie a namespace is something like a class that you cannot have objects of. But, unfortunately, many limitations of C++ prevent this from being literally true.
上一篇: 隔离Lua绑定游戏引擎其余部分的胶水代码
下一篇: 使用名称空间和本地名称