Each object does have its own sprite. I load up all the textures in the graphics class. Then I create a sprite and send it over to another class. I only do this once per class. Anyway thanks for the advice everyone
So essentially you are having your graphics manager create a sprite, passing that sprite a texture, then returning the sprite by value from the method so that elsewhere you are assigning that returned sprite to your class Sprite member? It's okay to do it that way, the Sprite copy and assignment operators are well implemented. It does result in some unnecessary copying, but since it's only done once per object it shouldn't be a problem, and it's a very miniscule amount of data to be copied anyway
Edit: My own personal preference in a situation like that is to have the graphic manager manage graphics only (ie, textures). I write a method, called something like getTexture(), which will load the named texture if not already loaded. Then rather than a method in my object class called setSprite(), I would call setTexture() instead. The reasoning for this is that it should not be the responsibility of the graphic manager to know what texture to assign a given object. The graphic manager should not be the one making the decision that this object gets the player texture, while that object gets the enemy texture. What if you want to implement more than one type of enemy? Or what about special effects? The graphic manager should just be a dumb class, solely responsible for managing graphics. (The Single Responsibility Principle) Giving it more responsibility than that only complicates the code when you want to expand it.
.In that case, your player creation might look like this instead:
In this case, it is trivial to use a different sprite image for another object.