Sign in to follow this  
squicklid

class heirarchy structure

Recommended Posts

If I have a class called Game, and it has private members called Screen and World, like so:
class Screen
{
public:
    Blit(blah);
};

class World
{
public:
    drawWorld();
};

class Game
{
private:
    Screen screen;
    World world;
}

How can I use the Blit function in Screen, from the World Class? I could obviously change both screen and world to be global, but is this desireable?

Share this post


Link to post
Share on other sites
World must know about Screen, either by having a global instance of Screen (there is just one ?) or by giving a reference to World during construction.


Version 1:
Screen screen;

Version 2:
class World
{
Screen& screen;
public:
World(Screen& screen) : screen(screen) { ... }
};

Share this post


Link to post
Share on other sites
No, you have just one defined in some .cc file. In the Screen.h you might append:


...
extern Screen screen;


Don't expect any order of global constructors.

Share this post


Link to post
Share on other sites
oh ok sounds good. I was orignally thinking of using a pointer, but i guess the reference variable is pretty much the same thing but without all the ->'s.

Share this post


Link to post
Share on other sites
Yes, the compiler internally handles it like a pointer, but a reference is more efficient (no checks for NULL when casting for example).

The global Screen object has the advantage that the reference can be resolved at compile time resulting in code without indirection.
The disadvantage is some kind of inflexibility, e.g. if you plan to have more than one screen.

Share this post


Link to post
Share on other sites
Aye, what if World had a member such as:

Screen * ptrDisplay;

That you could fill with a pointer to the screen?

for instance, in the constructor for the Game object...

Game()
{
screen.init(); // or Whatever initializes the screen
world.ptrDisplay = &screen;
}

And then, in drawWorld:

drawWorld()
{
// whatever you need to do to get it ready to blit
this->ptrDisplay->blit(Whatever needs blittin');
}

Would that help?

EDIT: Aye, a reference would work as well. I'm not quite sure why I always feel the need to use pointers instead... call me old fashioned. ;) Or stupid. ;)

Share this post


Link to post
Share on other sites
a singleton-like setup might work for you. What I mean by that is, don't make your screen a singleton class, because it may make a lot of sense down the line to be able to have multiple screens at the same time and all of that kinda stuff ... but create another class, something like ScreenManager or something, that simply provides the "global access" part of the singleton puzzle.

So you have a Screen class which supports whatever functions a screen supports.

And you have a World class, which supports managing all the things a world manages. And also has a function to draw the world onto a screen.

Then, for now, you simply a a very small ScreenManager class, which (in the first version) simple provides 2 functions: GetCurrentScreen(), and SetCurrentScreen() - and internally stores a pointer to a screen object.

Then your main creates the screen at app start time, sets it as the current screen, and deletes it at app cleanup time.

Then your World class simply uses GetCurrentScreen() whenever it needs a screen.

...

Later, when you want to have multiple different views of the same world, or multiple worlds or screens, you refactor a little bit of your code, for instance you can make drawWorld take the Screen it draws on as a parameter ... then your main or game can simple pass the current screen when it calls drawWorld. Another option would be to have a WorldView class, which has the logic for drawing a view on the screen, and has a pointer to a screen, and a pointer to a world ... then when you call Draw() on the WorldView object, it calls view.drawWorld(screen); or something like that ...

Share this post


Link to post
Share on other sites
Whoa, that was an intense description. But I think I understood it. I think I'm still gonna go with the reference object however. Because, I am only making a smalltime programming-practice game. But thanks anyway.

Share this post


Link to post
Share on other sites
If the Game object is calling a function on the World object then it can pass it the Screen object.

void World::draw(Screen* screen) {
//use screen
}

void Game::DoSomething() {
world.draw(&screen);
}

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this