Managing custom Screens in XNA 4.0

I'm going through the process of building my OOP skills, and have written an abstract Screen class with an update method that takes a KeyboardState and MouseState as parameters, and a draw method that takes a SpriteBatch as a parameter. The class also includes a bool isEnabled, along with methods to enable/disable it.

It's worked fine so far, extended these 开发者_开发技巧and used without a problem until it comes to moving from one screen to another. I want to know why the screen was disabled, and which to enable next.

At the moment I use an int variable within the Screen, and the main class checks if the class implementing Screen is disabled and has a "disabled reason" int. If so, it does an action based on that int. I guess that an int isn't the best choice and an Enum would be better?

But my real question is, is there a better way of relaying data back to the main class? Would I have to poll each disabled class to see if there's a "reason for being disabled code"?

I will only answer the following question:

I guess that an int isn't the best choice and an Enum would be better?

Even if you use a enumation you would still be using an integer value since an enumeration has a integer value associated with it.

the only benefit of an enumeration would be you would have a textual represenation of the reason instead of ( 0, 1, 2,3 .. ).

I guess that an int isn't the best choice and an Enum would be better?

Correct. Make an enum, for example:

enum DisabledReason { Something, SomethingElse; }

is there a better way of relaying data back to the main class? Would I have to poll each disabled class to see if there's a "reason for being disabled code"?

Give the base screen class an event - something like this (MSDN for EventHandler):

public event EventHandler<DisabledReason> Disabled;

Make the main class attach an event handler to the screens as it creates them.

Make the screen class call the Disabled event handler when it becomes disabled.

The upshot will be that the main class is informed why a screen becomes disabled, when it becomes disabled. You pass the this of the screen to the Disabled event as the source parameter - so the main class will know which screen the event is coming from.

(Note: this is very much a crash course on using events - do a bit more research on how to use events, if you need to.)

I'd suggest "borrowing" from the Game State Management sample on the Microsoft App Hub site. It's all about screen management. (Be sure to download the sample for Windows - unless your making a phone app).

The ScreenManager class is a reusable component that maintains a stack of one or more GameScreen instances. It coordinates the transitions from one screen to another, and takes care of routing user input to whichever screen is on top of the stack.

Even if you do end up "borrowing" code to figure out the solution, you can still get some good OOP principles out of it. EventHandlers are a classic example of the "observer" pattern.