ich programmiere an einem Spiel und benutze dabei die SFML Bibliothek. SFML bietet verschiedene Klassen an die von sf::Drawable abgeleitet sind, um im Fenster gezeichnet werden zu können, z.b. sf::Sprite für Bilder und sf::String für Texte.
Um Drawables zu haben, die nicht immer angezeigt werden, behelfe ich mir im Moment mit einem zusätzlichen bool, da sowas von SFML nicht unterstützt wird. Das funktioniert, ist aber etwas unpraktisch. Um den Drawable Klassen ein Show()/Hide() zur Verfügung zu stellen hab ich mir folgendes überlegt.

Ich habe eine Klasse

template <typename Base>
class ExtendedDrawable : public Base
{
    bool visible;

public:
    ExtendedDrawable() : visible(true)
    { }

    void Show() { visible = true; }
    void Hide() { visible = false; }

    // und noch mehr ...

protected:
    // Die Render Methode wird von sf::Drawable vorgegeben
    void Render(sf::RenderTarget& target) const
    {
        if (visible)
            Base::Render(target);
    }
};

und leite davon erweiterte sf::Sprite, sf::String und sowas ab:

namespace sfex
{
    typedef ExtendedDrawable<sf::Sprite> Sprite;
    typedef ExtendedDrawable<sf::String> String;
}

Die sfex::* Klassen sollten genau wie ihre Originalversionen aus sf:: benutzbar sein, auch im Zusammenspiel mit anderen SFML Funktionen.
Das ganze funktioniert für ein paar Testobjekte gut.

Jetzt zur eigentlichen Frage:
Gibt es bei so einer Vorgehensweise irgendwelche Probleme?
Ich möchte nicht alle Objekte und die ganzen Mechanismen mit den zusätzlichen bools umstellen, um dann in zwei Wochen zu merken, dass ich mir damit nur in den Fuß schieße

wichtig ist halt, dass die Methode auch virtual ist. Wenn Du sonst ein Basisklassenobjekt hast, das aber als eigentlichen Typen deine Klasse hat, wird sonst die Methode der Basisklasse aufgerufen. Auch der destructor von Base sollte virtual sein. Aber wenn SFML selbst Ableitungen anbietet, wird das wohl gegeben sein.

Ansonsten funktioniert Deine Variante, Vererbung ist eben eine Form der Erweiterung.

Eine andere wäre Komposition, Du könntest dann die Drawable-Klasse als Attribut halten, die üblichen Methoden anbieten und alle Aufrufe an die Drawable-Klasse weiterleiten. Vorteil ist die gesteigerte Dynamik, falls Deine Klasse noch mehr können sollte. Nachteil ist die Tipparbeit und v.a., dass Du dort, wo Drawable erwartet wird, nicht Deine Klasse übergeben kannst.

Dafür kriegst Du mit Vererbung z.B. nicht einen Text versteckt, sondern eben nur ein Basis-Drawable-Objekt. Wenn Du das über ein Attribut machst und beispielsweise über Templateparameter oder via constructor-Argument das Drawable übergibst, kannst Du jede Art von Drawable "verstecken".

Ich würde mir die Frage stellen, was Dein extended Drawable überhaupt soll. Wieso muss die Sichtbarkeit Teil des Objekts sein? Ist das der einzige Grund für eine neue Klasse oder können da auch noch weitere Eigenschaften dazu kommen? Wenn ja, welcher Art?