I've been think about how to create a system class that would be easy to change later for multi platform stuff mainly.
The idea is to have a CSystem class, it would have several derived classes like CGraphic, CSound, CNetwork, CMultithread and CInput. CSystem would be a global that on creation would create an instance of each of the derived classes and call there init functions.
I think this would make system into a singleton? Honestly I can't see an issue with this but maybe someone could enlighten me?
//The system constructor would be something like this...
CSystem::CSystem()
{
m_graphic = new CGraphic;
m_sound = new CSound;
//.... so on
}
//CSystem would have some getter functions and such to use each object.
CSystem::init()
{
m_graphic->init();
m_sound->init();
//....
}
int main()
{
CSystem sys;
//Assuming I had a CMesh class that stored a mesh and material
CMesh mesh(sys.getGraphic(), "Some_mesh", "Some_Material"); //this would be inside a visible game object so it would have other info like location.
//CMesh would just add a mesh and material to a map inside the graphic object so it could draw everything.
return 0;
}
I'm no expert, but it doesn't make much sense to me that you would be using Base Csystem to create instances of Derived classes. If CGraphic etc. derive from Csystem, it implies that it has all the functionality of the Base class, but is different in its own right.
I believe the design patterns for creating instances of objects are called factory patterns:
http://en.wikipedia.org/wiki/Factory_%28software_concept%29
Factories which store a set of pre-made objects and hand them out accordingly are referred to as "object pools".
So I would recommend creating a separate factory class to create instances of your derived classes, that would make more sense than having your Base class fulfil this function.
Again, I'm no expert - perhaps someone else around here can give you more specific and accurate advise.
I agree with NwN. And on top of that when anyone decides to use a singleton I've found that in 90% of the cases an alternative better (non-global) design can be found.
See it is somewhat pointless to make them derive from system. After I got into programming it was obvious. The reason for system class is just to hold game system the the graphic system or engine. There is no need for more then one of each system. I will look at that factory pattern though.
It's not actually a real global since its local to main.
A global could be accessed from anywhere the system object will be created in main. I suppose any item could access it at run time but its not really how it would work.
What would you do in this situation. Just considering the graphic class and not having a system class at all... It's not really needed other then to keep it simple for me. I only need 1 graphic engine object CGraphic it will have all graphic related functions, it will also have a map of CMesh objects. CMesh object will be created by all visible game objects. It will have data like the mesh, material, model matrix, possibly some other stuff related to lighting and which shaders to use if not the defaults. In order to draw everything in the world all it would require is a call to the CGraphic object to draw and it would handle it. Later if I needed to change from say opengl to DirectX it would be easy as I'd just change CGraphic class.
I've been think about how to create a system class that would be easy to change later for multi platform stuff mainly.
I feel like this is where abstract base classes come in handy. If you exposes your library through abstract base classes then you can implement derived classes in any way you want and even swap them out for different implementations without the public interface ever changing.