Inherit from sf::Sprite or add variable sf::Sprite?

[didii]

Inheritance:

class myClass : protected sf::Sprite {}

or adding it as member variable

class myClass {
    private sf::Sprite spr;
}

When using it as a variable it seems safer, but with inheritance it seems all a lot cleaner and more intuitive:

myClass obj;
// with inheritance
obj.loadFromFile("pic.png");
obj.setPosition(20,25);
window.draw(obj);
// with member variable
obj.getSpr()->loadFromFile("pic.png");
obj.getSpr()->setPosition(20,25);
obj.draw(window);

Are there any benefits by adding it as a member variable or is it all personal preference?



Edit: this actually should be in the general help, this is not only related to sf::Sprite but all other classes too.

[eigenbom]

It depends on what myClass actually is, but in general I prefer aggregation over inheritance. If its just a simple extension of sf::Sprite then inheritance is probably fine, but if it's say, some SuperAwesomeEntity thing, the internals of which may eventually contain shaders, multiple sf::sprites, vertex arrays, and who knows what, then having its own interface is better than adding to, or re-appropriating that of, sf::sprite, and then aggregation is far more flexible than inheritance.

[Nexus]

Inheritance:

class myClass : protected sf::Sprite {}

In several years of C++ programming, I have not come across a meaningful use case for protected inheritance. Maybe you can tell me one?

When using it as a variable it seems safer, but with inheritance it seems all a lot cleaner and more intuitive:

Assuming myClass is a logical object like an enemy (use descriptive names), it should encapsulate its attributes. Do not access the sprite directly, but hide it as a private member. Ideally, the interface is kept free from SFML, except for classes like sf::Vector2f that are not only related to graphics.

The advantage of data encapsulation is the possibility to change the implementation while retaining the interface. If you decide to represent your enemy suddenly with multiple sprites, a shape or a vertex array, and have a inheritance approach or getSpr() function, you need to refactor every interaction with enemies. If the sprite is hidden, the client code needn't be touched, modifications are local to the implementation of the class.

By the way, these are basic OOP principles, I suggest you read something about that topic