monTruc.getDrawable
Ca c'est typique d'une mauvaise conception (désolé ).
Une classe doit être pensée en terme de services ("dessine toi") plutôt que de données ("donne moi un truc à dessiner"). C'est beaucoup plus flexible, encapsulé et donc maintenable.
Ce n'est pas que je penses en terme de données, mais je n'aime pas faire hériter mes classes de la SFML, honnêtement je ne le fais jamais car pour moi cela n'a pas de sens. Pour moi un personnage (par exemple) n'EST PAS UN drawable, mais A UNE image que je dois dessiner, etc...
L'utilisateur de la classe n'a en effet pas à savoir quel genre de drawable utilise la classe pour réaliser son dessin ;
je ne comprends pas ce que tu essaies de dire, tu peux développer ?
d'ailleurs tu fais comment pour les entités qui ont besoin de dessiner plusieurs drawables d'un coup ?
Au lieu d'encapsuler dans une seule méthode tous mes appels à draw, j'aurais une méthode pour encapsuler tous mes appels aux getters (d'ailleurs assez particulier une classe à sémantique d'entité (si tu l'as employé dans ce sens) qui posséderait plusieurs drawables, mais ça reste largement imaginable), ce qui revient au même (à part que, si j'ai bien compris, avoir des getters sur ses drawables pour les appeler dans la gameloop, c'est maaal). Non pour être honnête, surement que dans ce cas là j'aurais écris une méthode draw, mais c'était juste pour dire que dans l'autre sens c'est pas aussi gênant que tu le dis. je redéfinierai draw dans les cas où la phase de conception m'y a conduit inévitablement
Du coup, comme je le disais, une classe dessinable bien conçue aura une fonction draw (que ce soit via sf::Drawable ou à sa propre sauce), et celle-ci doit forcément prendre en paramètre le truc dans lequel elle doit dessiner. Pour moi il n'y a pas vraiment d'autre design qui soit valable, pour cette problématique en particulier.
Donc soit on hérite des drawables (soit à sa sauce, ok), soit notre classe est mal conçue pour cette problématique en particulier (tu veux dire un programme avec plein d'objets à dessiner ?) ? Désolé je fais pas exprès de mal comprendre, mais voilà ce que je comprends.
Parce que si on a un (ou deux) sprite dans notre classe, au lieu d'hériter de drawable, dans la gameloop on aura sprite.draw(App) au lieu de App.draw(sprite), je trouve pas ça hyper gênant, même pour la maintenabilité..