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!
Passing Objects
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.
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! 
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":
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?
