Jump to content
  • Advertisement
Sign in to follow this  

Delegating the Creation of Concrete Classes

This topic is 4235 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

I have a question about just when and where the choice of which implementation of an abstract class should be used should be made. In my engine, I've created some abstract base classes for certain objects (currently only graphical objects, as I'm working on the graphics subsystem first). For instance, Image, Texture, and Device are all abstract classes that serve as an interface for their concrete counterparts, including ILImage, SDLDevice, GLTexture, etc.. This gives me a great deal of flexibility, including API independance. :-) The problem I'm having is this: where should I delegate the responsiblity of creating the right concrete type? At the moment, Device provides methods for creating graphical objects, such as makeImage(), makeTexture(), makeShader(), etc.. This means the user can create an SDLDevice and effectively choose to use SDL/OpenGL in that one step; calls to makeTexture(), for example, will return GLTextures. But what about other subsystems? My audio subsystem also has a Device object and I figure I can use the same scheme. To create such devices, there's an Application interface that provides makeGraphicsDevice() and makeAudioDevice() methods. This way, the user creates an Application (rather than creating each Device) and the correct concrete Devices are made for them (and these in turn provide the correct concrete classes in their subsystem). But what about the input subsystem? There is no Device there. There are abstract bases included Keyboard, Mouse, and Joystick, but no "all powerful" Device to make them with. Is it right to make the user choose here? Should they have to create an SDLJoystick manually if they chose to create an SDLApplication? If not, where would be the appropriate place to put a makeJoystick() function? In the Application interface? Any help is appreciated. Thanks! :-)

Share this post


Link to post
Share on other sites
Advertisement
One thing you can do is to require the user create a configuration object and pass it as a parameter to the subsystems when they are created. That would ensure that the configuration is determined in one place rather than several.

As for the case where there is no class to encapsulate a factory method, I usually just make it a static (C++) member function of the base class. However, why can't you make an Input subsystem class like you did for graphics and audio?

Share this post


Link to post
Share on other sites
Quote:
Original post by JohnBolton
However, why can't you make an Input subsystem class like you did for graphics and audio?
Good point. :-P I guess my "Device" naming convention made it seem strange to me. However, I've been considering some name changes. "Device" makes sense to me in the audio and graphics contexts, but the ambiguous naming may get confusing. Instead, I thought "Renderer" (for Graphics::Device) and "Mixer" (for Audio::Device) may be better.

In that case, InputReader could be the analogous input subsystem class. In fact, using an InputReader actually seems like a good idea; it gives me a central place to process input events and transmit them through different objects (Keyboard, Mouse, Joystick, etc.). I've been trying to process events within Application, but I've run into a lot of problems. This could solve those problems. :-)

Thanks for the reply. :-) Any other comments or suggestions...? Does this make sense, or am I just adding more flaws into my design?

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!