🔒 Locked

Simple Application Design

Started by BenBowen Apr 3, 2011 at 5:16 PM 4 replies 1.5k views

Original Post

Apr 3, 2011 at 5:16 PM

For now, my game-engine/application-library uses callbacks. For each window you create, you make four callbacks to handle what happens when the window is opened, updated, rendered, and closed. The entire program is started with the "SystemBegin" callback, which allows you to initialize your application, and create windows. For example:

bool SystemBegin()
 {
 if (!mainWindow.Create("Main Window", 300, 500, true))
 {
 return false;
 }
 
 mainWindow.GiveControllers(MainOpen, MainClose, MainUpdate, MainRender);
 mainWindow.Show(false);
 
 return true;
 }

I don't have much experience with other application systems, so I would like to hear some insight. What would be the better way to design an application?

simpler

Apr 3, 2011 at 6:59 PM

Just curios, can the callback point to a member-function of an object? If so - how did you do it?

BenBowen

Apr 3, 2011 at 7:43 PM

No, it can't. Should I make this more object oriented?

rip-off

Apr 3, 2011 at 9:36 PM

Yes. Stateless callbacks force the rest of the application to mould around this API choice. One ends up requiring globals to get anything done.

Look at something like boost::function, or provide pure virtual interfaces with a single virtual function that the client can implement.

BenBowen

Apr 6, 2011 at 4:08 PM

Could you give me an example of such a class? I don't know what a 'pure virtual interface' is.

rip-off

Apr 6, 2011 at 4:40 PM

It is a class with no implementation (apart from a virtual destructor). All member functions are pure virtual (i.e. abstract) and there are no member variables.

E.g.


 class IRenderCallback
 {
 public:
 virtual ~IRenderCallback()
 {
 }
 
 virtual void onRender(/* ... */) = 0;
 };
 
 int main()
 {
 // ...
 MyRenderCallback callback(/* whatever state */);
 mainWindow.setRenderCallback(&callback);
 }

This gives the maximum flexibility to the caller, as they can choose a stateless or stateful implementation if they want. Boost::function is just a nicer version of this. It is clearer in intent, and avoids a bunch of otherwise useless classes that only exist to provide an interface to implement.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.