Design approach on a program with many GUI screens

I've terribly confused myself to the point of no return and feel my project is ballooning too huge to keep up with my current ways.

In a nutshell:

1) There are many graphical screens (windows), each screen is a class defined in its own .cpp with a accompanying .h header w/ public & private decelerations.

2) I'm using the FLTK GUI toolkit, so when I leave a screen I call "hide()" on it, which I assume开发者_Go百科 does garbage collection, and then I create a new instance of whatever screen is to follow.

My issue is that if a screen (Screen A lets call it) creates another screen (Screen B), then I must include screen B's header file in Screen A, and I make a global pointer to Screen B in Screen A's .cpp.

ie. A pseuodocode for Screen A

#include "screenb.h"

ScreenB* screenb_ptr; // global

...
Bunch of Code, constructors, deconstructors, etc
...

void ScreenA::exit_and_make_screen_b()
{
    ScreenA.hide();
    screenb_ptr = new ScreenB();
}

Is this the best approach? I feel it's sloppy (and a memory leak?) and I should have something like a dummy .cpp/.h that keeps track of a bunch of extern-qualified pointers; especially as sometimes I must go back/forward screens (i.e. Can jump back to a Main Menu screen from a miltiple other screens). Any advice is appreciated!

Here are a few suggestions:

1. Create a new header file with all of your screen includes. Then you can just include this one header file and capture all of your other screen header files.
2. You might consider a screen manager that keeps all of the references to your screens. Navigation between screens is then left up to your screen manager who handles all references and pointers. This way you are not coupling screens together but they talk through a common mediator.

For instance:

screenManager->NavigateScreen( SCREEN_USER_PROFILE );

All of your screens can inherit from a base class that holds a pointer to the screen manager (which they take through their constructor or grab from a static singleton instance). This way all of your screens have the ability to request a new screen navigation.

BTW: I'm not entirely sure about FLTK's memory structure. Hiding the screen might not delete memory at all, but just hide the GUI representation of the window, allowing you to open it again later in the same state.

A good method for GUI is Model-View-Controller architecture, where you have a controller to operate the GUI as necessary.

This would manifest itself more as:

WindowManager wm;

void ScreenA::exit()
{
        wm.registerExit(screenb_ptr);
        wm.actOnExit();
}

Or some such similar thing to have a central orchestrator of your windows. This allows for:

• Pluggable interfaces
• Better organization
• Guards against bugs