• Advertisement
Sign in to follow this  

Passing Objects

This topic is 1271 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Right now I have many different objects, many of which rely on several other objects to operate. I have a graphics library wrapper, sprite, button, collision, heads up display and many other classes. I'm thinking about breaking it up even further to specialized classes but I'm thinking to myself, will I have to pass a hundred objects into each class? For instance, a button class requires the graphics library, event manager, sound manager, its x and y position, width height, filepath etc... My constructors are getting longer and longer! Is there a better way to manage my code? Maybe some sort of manager class that holds all of the above that I can pass to each object? Or is that bad practice because I'm giving all of the dependent classes too much access to other parts of the game? What's the right way to do this? Any help would be much appreciated, thank you!

Share this post


Link to post
Share on other sites
Advertisement

Your code is too coupled, which means that your classes are too dependent on each other. Coupling usually indicates a poor design. I advise you to read this. It is a good articles that explains coupling and how you can reduce it. It will save you a great deal of headaches later on in the development process.

Share this post


Link to post
Share on other sites

For instance, a button class requires the graphics library, event manager, sound manager, its x and y position, width height, filepath etc...

 
Are you aware of initializer lists? They help clean up your constructors a decent amount.
 
Also, if you are using C++11 (which you should start using if you're not already), you can initialize class members directly in the class declaration:

class MyClass
{
    int x = 0;
    int y = 0;
    std::string imageFilepath = "../My/Default/Path/To/Image.png";
};

 
Coupled with function-overloading the constructor, these C++ features should help clean things up. You might also have some higher level architectural problems, but I'm not sure.
 

You haven't even seen his code. How would you know if it's coupled? This whole post is built on a baseless assumption.

 
Oh yeah? Well then your code is too coupled also! tongue.png

Share this post


Link to post
Share on other sites

How would you know if it's coupled?

It was described:

 


For instance, a button class requires the graphics library, event manager, sound manager, its x and y position, width height, filepath etc...

This is a classic highly coupled design.

 

Some more reading which might help, the SOLID object oriented principles from "objectmentor":

Edited by rip-off

Share this post


Link to post
Share on other sites

Some coupling is good - but only where it makes sense to have it : the articles suggested by Rip-off should help differentiate.

 

You mention having "event manager" - One way to reduce coupling between your button and your sound manager could be to leverage your event system and use it for triggering your sound effect by just sending a "pressed" event along with the sound effect to play : If the button is already hooked up to trigger a particular event in the game, why not have the sound manager (or something along the lines of a UI sound manager ) listen for it as well?

 

Similarly, you could rework your code such that a button is merely a data structure with position, dimensions, sound effect names, trigger, etc. and have higher level components such as a UIRenderer go through the list/hierarchy of UI elements and render them as required - some benefits of this would be :

 

  • No more coupling between the rendering/visuals & your UI elements
  • Ability to write your UIRenderer and substitute it for a different implementation later on if your requirements change - it would also make it easier to ensure visual consistency throughout your interface.
  • Ability to batch render UI elements & display them in a coherent way : eg. you place a button that is too big to fit inside a frame and have to clamp it. Another example would be managing dynamic layouts without having to manually change the position/scale of your UI elements.

Hope this helps a bit?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement