Design issue

Quote:

Original post by PierreD Is it possible to make these different member classes interact with each other? Like if I want to report an error with the graphics class, or calling any method from another class from any other? Or is my design really flawed, like I've come to think in the past few hours.

You've designed yourself a nice procedural system-based design (the fact that you mention interactions between classes as opposed to interaction between class instances is a big hint). There's nothing wrong with it per se, as long as it solves your problem. And implementing such a system is quite possible.

Of course, you have to ask yourself whether you really need this. Does your video rendering code really need to access your audio playback code freely?

Eh actually you're right, so it would be better if I used a namespace for error logging instead of making it a member of the primary class, that way the instances of the different classes (:P) would not need to access each other.

You could also look at the links required between your classes:

Graphics uses Logging.
Audio uses Logging.
Logging uses nothing.

Fortunately, nothing is cyclic.


Now if you decided to instantiate your classes, you could require that the Graphics and Audio class constructors take a pointer to a Logger class.

You would of course have to make sure that the logger was constructed first and destroyed last.

Your kernel class would then perhaps contain pointers to all three classes, which would allow you to use inherited versions of them.

Thus your kernel would either be constructed last and have it's constructor take pointers to Graphics, Audio and Logger classes (which is probably best), or somehow you could provide these objects afterward, possibly with Kernel::set_logger(Logger* logger) or similar (which would then bring up the issue of what to do with logger calls when the logger is NULL etc).


This way is more modular and perhaps better designed, but it takes more work.

Ah thanks, I'll look into that solution too, though it seems a bit more complicated.