Jump to content
  • Advertisement
Sign in to follow this  
leiavoia

One interface for everything, or each subsystem for itself?

This topic is 4819 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

What's your opinion on this: Should i establish all my subsystems independently and let objects access them as needed, or should i have one monumental "core engine interface"? It's more of an organizational question. If there is only one interface, all these objects won't have to depend on all the subsystems. In fact, in case of total subsystem failure ("Dude! Where's my soundcard?"), the "core interface" approach good just simply choose to do nothing with incoming function calls. But, it's one more layer of indirection. With the unified interface approach, you would never see client objects with this: #include "Sound.h" #include "Graphics.h" #include "FontDrawingFunctions.h" #include "ObjectManager.h" #include "ResourceManager.h" ... etc ... All the functions of those respective subsystems would simply be "copied" into a big unified interface. Now objects would only have to include this: #include "CoreInterface.h" The interface object would simply redirect to the appropriate subsytem:
void CoreInterface::DoThing( param ) {
   subsystem->DoThing( param );
   }
This is basically the Mediator pattern, giving the Mediator exclusive access to the subsystems. What do you think? Good idea? Bad idea?

Share this post


Link to post
Share on other sites
Advertisement
I have this problem a lot - where to draw the line at nice'n'clean interfaces vs. spending too much time writing them. In this case, I'd probably go for the direct access method, but it also depends on how many calls would be redirected through the interface. If it's only a few, then an interface could be a good idea. But, if there will be a lot of different function calls redirected through, then redesigns of your subsystems could mean lots of maintenance work updating the interface.

Share this post


Link to post
Share on other sites
Not that I practice what I preach, but ideologically, #2 is what I'd prefer. Why?
Because I'd like a unified interface to subsystem #2 for example. If the subsystem changes, or if I allow multiple subsystems [such as allowing multiple renderers] I don't want to have to make changes in many areas of my code. Just in the engine interface/translation layer.

That said, I'm not sure I'd have a unified engine interface with exclusive access. Something more along the lines of client class[es] to abstract the subsystems one at a time might be more practical.

Share this post


Link to post
Share on other sites
My personal opinion is that a big unified interface would happen to be the worst thing you could do.

If you must, you could use a central "Kernel" object or something similar which provides access to all subsystems like this:

// Subsystems
class InputServer;
class AudioServer;
class StorageServer;

class Kernel {
// ...

InputServer &getInputServer() { return m_InputServer; }
AudioServer &getAudioServer() { return m_AudioServer; }
StorageServer &getStorageServer() { return m_StorageServer; }
};



Having a large unified interface would enforce a spider-web design, where everything is connected to everything else, making it hard to reuse, update or replace parts of your project (which is likely to happen for a large thing like an engine).

-Markus-

Share this post


Link to post
Share on other sites
I'm an avid supporter of code seperation so I endorse method 2. In use layered and interface design with all my projects and have never had any problems with them. In fact it generally makes things more effecient,more productive and promotes code reusablity.

Consider this, The client object only needs to know how to interact with the user, it should not concern it self with what those interactions do it just passes the appropriete message to the engine. The engine will then inform the relevent objects of what to do.

The point of this is that if you change, add, or remove any subsystem the only class you will need to update is the engine interface, everything else should continue to function as normal with no knowledge that anything has changed.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!