c++ - Is creating a base class for all applications of a particular type good design? -

I am trying to write a graphics application in C ++. It currently uses Ogre for display, but I want it to work with Irrilicht or any other engine, even a custom rendering engine that supports my needs is a big question, So I appreciate the help for tagging / cleaning again (if necessary). I will start with a little background.

There are three major states in the application:
1. Display a rasterized view. 2. Display the detected version of one of the same views. 3. Display a hybrid version of the scene

Obviously, I can split my application into four main parts: 1. A state management system, to switch between the above mode.
2. An input system that can get both keyboard and mouse input.
3. Raster engine used for display.
4. Ray Tracing Systems

Any apps that include the above requirements need to be enabled:
1. Create a window.
2. Do all the steps necessary to allow rendering in that window.
3. Start Input Systems
4. Start the State Manager.
5. Start looping (and rendering!).

I want to be able to change the rendering engine / state manager / input system / ray tracing system at any given time, as long as some of the minimum requirements are met. Imho, this implementation needs to be different from the interface. Keeping this in mind, I have created the interface for the above system

At that time, I saw that the application also has a common 'interface', so I thought it was possible to put it out in an ApplicationBase class with virtual methods Was there. Uses a specific application, such as Ogre for window creation, rendering, etc. This class will obtain and apply it.

My first question is - is it a good idea to do such a design?

Here is the code for the base class:

  #ifndef APPLICATION_H # Define APPLICATION_H Namespace hybrid {// Next declaration square class; Class input system; // Base Class Class Application {Personal: Statmanager * Statmanager; for all your apps using Hybrid Rendering; Input system * input_system; Public: Application () {try {// State Manager initialise_state_manager (); // Create Input System initialize_input_system (); } Hold (...) // change it later {// throw another exception}} ~ application () {remove state_manager; Remove input_system; } // If one of these fails, then it throws an // exception. Virtual zero initialise_state_manager () = 0; Virtual Zero initialis_input_system () = 0; Virtual Zero create_window () = 0; // other methods}; #endif  

When I use Ogre, then I trust by creating a window on OGRE. For this, Ogre needs to be started before the window () function is called in my derived class. Of course, like this, MakeWindows are being said earlier! This leaves me with the following options: 1. Leave the base square creator blank.
2. In the implementation of the derivative class, the part of the ceremony performed ongra beau.
3. Add an initial render system Pure virtual function runs the risk of compiling a dummy implementation in this derived class for my base class, which has no use for such a method.

My second question- What are your recommendations on the choice of one of these strategies to start the OGRE?

You are matching two unrelated functions in one square. First of all, it acts as a syntax shortcut to declare and start member state member and input system members. Second, this summary declares the create_window function.

If you think that should be a normal interface - write an interface (pure abstract class).

In addition, class like the OgreManager, with some type initialization (looping etc.) methods and event callback. Since the app can create and launch this object at any time, your second question is automatically resolved.

Your design can save a few lines to create new application objects, but the price is maintaining a soup-like master with a possible long legacy line.

Use the interface and callback.

PS: Calling a virtual function in the constructor does not mean what you probably expect.