Question about god classes.
Lets say I have many classes that will be used in a game (Rendering class, music class, scripting class...) and I have one classe that takes these classes and in the darkness binds them. Is this class a God class still?
Depends on how tightly coupled it is to the many classes.
Refer to the meditator pattern.
Refer to the meditator pattern.
quote:Original post by Magmai Kai Holmlor
Depends on how tightly coupled it is to the many classes.
Refer to the meditator pattern.
Well, this Lord of the Classes would just act as a messaging system that the other classes could use to communicate with each other.
EDIT: I forgot to ask something. Why do people have beefs with god classes anyway? How else can I tie everything together in my program if not with one class?
[edited by - tHiSiSbOb on April 3, 2004 2:58:21 PM]
quote:Original post by tHiSiSbOb
How else can I tie everything together in my program if not with one class?
whit name spaces. but you probably ment class solution.
[edited by - Craazer on April 3, 2004 3:19:51 PM]
quote:Original post by Magmai Kai Holmlor
Refer to the meditator pattern.
Hmmm, I thought that was the pattern that never actually did anything... (compare the sleep-pattern)
thats the first time i''ve heard a master processing system called a god class, but sure why the heck not, we need more terms like that. just imagine in 20 years.
Programer: So i tooketh the arcane IPC of sorlan a wrapethed it about the sinfull API of quarlacran. then, from the higest heavens arived the GOD class which unfied all classes under one proud bane and beat back memory leaks into the lowest pits of the garbage bin.
Programer: So i tooketh the arcane IPC of sorlan a wrapethed it about the sinfull API of quarlacran. then, from the higest heavens arived the GOD class which unfied all classes under one proud bane and beat back memory leaks into the lowest pits of the garbage bin.
quote:Original post by Cibressus
thats the first time i''ve heard a master processing system called a god class, but sure why the heck not, we need more terms like that. just imagine in 20 years.
Programer: So i tooketh the arcane IPC of sorlan a wrapethed it about the sinfull API of quarlacran. then, from the higest heavens arived the GOD class which unfied all classes under one proud bane and beat back memory leaks into the lowest pits of the garbage bin.
LOL, really funny
I would say tha rather than having a GOD class I like to have a Systems class in my engine. In this System class I can then Add loaded modules and sort them accorting to cathegorys. Like:
Renderer - GLRenderer, D3DRenderer
Sound - DXSound, SomeOtherSound
etc...
And also have an ActiveSystems map where you for each cathegory have an active System eg:
Renderer - D3DRenderer
Sound - SomeOtherSound
Then this class could export a function like:
Module GetModule(const char* sModuleID, void** &pInterface);
to every module while the module is loaded. Now every module has access to other modules...
The best way of loading cathegorys and modules would be to have a script file like core.cfg and read from that file and load all the cathegorys and modules. This way you can later in the developement add a new system cathegory like:
Script - CLikeScriptSystem, HaskelLikeScriptSystem
SceneManager - OutDoorSceeneManager, InDoorSceeneManager
This is done easily by loading another .cfg file...
And now each System can use the new loaded module you
newly created.
I think it''s better to have a structure like this rather than having a GOD class or having namespaces.
The only negative I can find with this is that everything is built on Interfaces and sometimes it can be hard to build all the Systems with a common interface for each cathegory. Though if you manage to do this you will have a very flexible engine where you can add new Systems by simply creating DLL''s and later on activate the system from a .cfg file. The only thing I you will need to actually recompile for is if you change something structurally or want to add another platform... then you will need to add ModuleLoading functions etc...
Renderer - GLRenderer, D3DRenderer
Sound - DXSound, SomeOtherSound
etc...
And also have an ActiveSystems map where you for each cathegory have an active System eg:
Renderer - D3DRenderer
Sound - SomeOtherSound
Then this class could export a function like:
Module GetModule(const char* sModuleID, void** &pInterface);
to every module while the module is loaded. Now every module has access to other modules...
The best way of loading cathegorys and modules would be to have a script file like core.cfg and read from that file and load all the cathegorys and modules. This way you can later in the developement add a new system cathegory like:
Script - CLikeScriptSystem, HaskelLikeScriptSystem
SceneManager - OutDoorSceeneManager, InDoorSceeneManager
This is done easily by loading another .cfg file...
And now each System can use the new loaded module you
newly created.
I think it''s better to have a structure like this rather than having a GOD class or having namespaces.
The only negative I can find with this is that everything is built on Interfaces and sometimes it can be hard to build all the Systems with a common interface for each cathegory. Though if you manage to do this you will have a very flexible engine where you can add new Systems by simply creating DLL''s and later on activate the system from a .cfg file. The only thing I you will need to actually recompile for is if you change something structurally or want to add another platform... then you will need to add ModuleLoading functions etc...
I usually use a system like this:
So in a way, my CGame class is basically a God class, except it does more than just combine all of the other classes and interacts with them - it does plenty of its own work, i.e. non-engine specific game stuff.
class CGame{public: Run(); private: Init(); MainLoop(); Shutdown(); CGraphics m_graphics; CSound m_sound; CNetwork m_network;... // Game vars}; CGame::Run(){ Init(); while(gameIsRunning) // GetMessage/PeekMessage { MainLoop(); } Shutdown();}CGame::MainLoop(){ switch(gameState) { ... case SOME_STATE: { m_network.ReceiveDataFromClients(); GetInput(); ProcessInput(); m_graphics.DrawSomeStuff(); m_sound.PlaySomeSounds(); m_network.SendDataToClients(); break; } }}
So in a way, my CGame class is basically a God class, except it does more than just combine all of the other classes and interacts with them - it does plenty of its own work, i.e. non-engine specific game stuff.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement