Best method for interaction between classes

[codeblue9955]

I have been in game dev for a couple of years. I took some time off for school and now I'm getting back into development once again. I used C# for a rather long time, but now I am moving towards using C++ more. The questions I have is what is the best method to control interactions between classes. For example, I have a player class, an enemy class, and a TileManager class. The player class needs to be able to access the tile manager in order to check collisions, the enemy class needs access to the player class for position in order to be able to move towards the player, etc. I'm wondering the best way to go about this. Perhaps you could have access functions to pass pointers into the functions of other classes, but I am unsure if there is a better method.
I've put a little code below to try to make sure my question is understood. The code will not compile. It is simply for demonstration purposes(yes, I know I don't create instances).

Thanks,

Code: Select all

class Player
{
     int x, y;
     public:
     int * GetX();
     int * GetY();
     void Update();
};

class TileManager
{
     Tile tiles[];
     public:
     Tile * GetTiles();
};
class Enemy
{
     int x, y;
     public:
     void Update(int * playerX, int * playerY);
};

void Update()
{
     player.Update(TileManager.GetTiles());
     enemy.Update(Player.GetX(), Player.GetY());
}

[superLED]

I would make a static class for the player.
That way, you can include "player.h" and use "Player::getX();"

And for the enemies, make a static class that holds all the enemies, so you can do like this: "Enemies::getEnemy(3)->kill();"

And the same for the tileManager. "if(TileManager::getTile(43)->isSolid()) { };"

A little while ago, I had to pass &player to every function in another class to access him. enemy.checkCollision(&player)... and so forth.
The same with my Input class and all that stuff.
When I have a class that I will be using all over the place, I make it either a static class or make a static class that holds every instance of that object.

[Falco Girgis]

I would make a static class for the player.
That way, you can include "player.h" and use "Player::getX();"

And for the enemies, make a static class that holds all the enemies, so you can do like this: "Enemies::getEnemy(3)->kill();"

And the same for the tileManager. "if(TileManager::getTile(43)->isSolid()) { };"

A little while ago, I had to pass &player to every function in another class to access him. enemy.checkCollision(&player)... and so forth.
The same with my Input class and all that stuff.
When I have a class that I will be using all over the place, I make it either a static class or make a static class that holds every instance of that object.

What you are doing is basically no different than a singleton. I wouldn't recommend that.

The question that codeblue9955 is asking is one hell of a loaded question. This is essentially the biggest question in engine development--or any other form of object-oriented software development. It encompasses the entire field of design patterns. It is object-oriented development.

There is no single answer to your question. There is no single mechanism that that you can employ to communicate between every class that will always be the best case (unless you go the inexperienced route and either make everything static or a singleton). The preferred design patterns are different for different areas of your software architecture.

I remember asking the exact same question when I began my own development. I originally started with C, where that shit didn't matter. Then I went to C++, and I began abusing singletons/global statics like every other newbie out there... Then I began learning the art of understanding which scenarios warranted which design patterns.

I wish that I could offer you a less cryptic post than this one, but the truth is that the "real" answer to this question would require me writing an entire engine for you. Different classes communicate differently. The best piece of advice that I can give is to read up on design patterns and look at other peoples' software architecture.

[short]

A design pattern I really have been taking a liking too lately (which in some scenarios really helps) is dependency injection. It requires that each class takes all of it's dependencies as parameters (usually in the constructor).

It is appropriate when used correctly, and if abused can very quickly turn into a "service locator" anti-pattern so you must be careful. There's a lot of information on it throughout the web if you peruse google, however it means you need to design your engine it terms of interfaces (which is a wonderful thing).

I have to reiterate, it's easy to overuse, and can definitely degenerate into a glorified singleton (and the same down-sides when it comes to multi-threading), but I recommend looking into it / trying it out, it's just another tool for you.

[codeblue9955]

Yeah, I think the largest problem with my C# code was I made a lot of singletons. It made it really hard to maintain. I'm going to be attempting a component based system. I'll read up on design patterns and see where I get. Are there any good books to read on design patterns for approaching such situations? I feel pretty comfortable with coding, but knowing the best approach to take is rather hard. I will probably learn more coding and seeing where problems occur though.
Thanks for your time,
Cody