Static Classes or Instance Pointers

Question

Background:

I currently have a series of three classes related to the game. I previously made games using Unity, where you access components like the camera using the features available throughout the code. However, my current setup depends on the instances of each class dispatched by other classes. See the following report:

class World{ }; class Game{ Camera* camera; World* world; }; class Camera{ Game* game; World* world; }; 

Questions:

• Is this the result of poor design or are there times when customization like this is justified?

• Should I use static classes on top of the current setup, as this will refine the code and no more than one instance of each class has ever been used?

• What are the possible disadvantages of using static classes over cases?

Edit: why do they need to contact each other.

Why the camera needs the world: The camera needs access to the world, since the world must be made in terms of the camera. The camera launches a render of the world depending on what it sees. Rendering starts from various methods in the camera, for example, when it moves.

When the camera is drawn, it draws what it sees, for example, the world. To paint the world, the camera needs access to the world.

Why the camera needs a game: The game has values ​​such as FPS, which are used by the camera to display the overlay of debug information.

Answer 1

Three classes that are closely related offer some dubious design options. Try changing your code so that, for example, Camera receives a pointer or link to World , passed only in those methods where you really need to deal with World . Also consider whether Camera and World need a pointer to Game . Conceptually, it would be wiser if the Game has World and has Camera , and not all three objects belonging to someone (who)?

The relationship between Game and Camera still only assumes that you must pass Game or even better the corresponding FROM Game data as method arguments to the Camera draw method.

Answer 2

If you have a static (global) instance of any class (s), it can be accessed from anywhere in the world, and it can turn out to be a "big ball of dirt", making it difficult to keep track of what it uses or needs.

One idea of ​​the so-called "SOLID" principles is that

"Details must depend on abstractions."

Currently, introducing additional abstract base classes (or interfaces in languages ​​that support them) may seem complicated, but it can help you find which parts of each object you need, where you want it from, and let you introduce another Game in the future.

One approach might look like this:

 #include <iostream> class World { public: int Info() { return 0; } }; //An abstract base class class IGame { public: virtual ~IGame() = 0 {} virtual int FPS() = 0; }; //One specific type of game class Game : public IGame { public: int FPS() { return 0; } }; class Camera { public: Camera(Game * game, World * world) : game(game), world(world) { } void Move() { //actually move first then ... Draw(); } void Draw() { //This will show us what needs to be public in the other classes std::cout << world->Info() << '\n'; if (game) std::cout << game->FPS() << '\n'; } private: IGame* game; World* world; }; int main() { World world; Game game; Camera camera(&game, &world); camera.Move(); } 

(to the principle of dependency inversion), as discussed in this question

It may seem redundant for what you are doing, but it brings you closer to "everything depends on something abstract," and not on "everything that depends on everything else."