State with namespaces and locals - or classes?

Question

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:

• RAII conform
• All state could be packed into a single CState class which contains the instances of the modules
• Good for making sure that resources are deleted and allocated properly

My questions:

• Should I consider refactoring my engine modules from namespaces to managed classes? Why (not)?

Answer 1

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.