Yep. Le drapeau rouge, c'est les 2 niveaux/3 classes abstraites pour pas grand chose, qui vient probablement d'une volonte de mutualiser qq proprietes plutot qu'un reel comportement, ainsi qu'un probable manque d'analyse du domaine (bon, la je suppute base sur mon experience, vu qu'il n'y a pas de domaine dans son exemple "en l'air", on peut pas reprocher de pas avoir analyse).
Regle de base de la programation objet: l'heritage coute trop cher pour ce qu'il rapporte, et les profs feraient bien d'arreter d'enseigner ca en premier quand ils abordent le sujet.
Regardez un framework comme Cocoa, vous aurez du mal a trouver qq chose qui descend plus bas que 2 niveaux, et on parle d'un framework UI vraiment complet. De meme chez Foundation, et meme Java, legendaire pour etre super complexe dans sa version ee, descends rarement a ce niveau dans sa version se (forte de qq milliers de classes, quand meme).
On ne le repetera jamais assez: wide and shallow, pas deep and narrow.
Sans avoir plus d'info que "c'est pour un jeu", et j'imagine un truc a la gta vu la diversite des vehicules existants:
Une interface Vehicule, avec assez peu de choses dedans (probablement une ou deux methods, pour faire bouger le machin).
Une classe concrete par vehicule. Probablement pas de classe abstraite, j'ai du mal a voir en quoi une voiture et une moto se comportent de facon similaire. Les differences un 4x4 et une twingo se modelisent par des donnees, pas de classes.
Une voiture volante, si tant qu'elle se comprte vraiment comme une voiture au sol rt comme un avion en l'air, serait une implementation de Vehicule qui compose une voiture et un avion.
Probleme resolu, et la meme solution te permet de faire une soucoupe roulante ou un avion sous marin si tu veux.
Ca implique evidemment que les classes soient fortement data driven, sinon ca marche pas terrible, et du coup on en revient au sujet principal, qui a effectivement l'air plus adapte pour ce genre de problematique, vu la flexibilite que ca apporte (apres, en pratique, j'en sais rien, je connais pas assez le sujet).
[^] # Re: « préférer la composition à l’héritage »
Posté par groumly . En réponse à la dépêche Je crée mon jeu vidéo E01 : les systèmes à entités. Évalué à 0.
Yep. Le drapeau rouge, c'est les 2 niveaux/3 classes abstraites pour pas grand chose, qui vient probablement d'une volonte de mutualiser qq proprietes plutot qu'un reel comportement, ainsi qu'un probable manque d'analyse du domaine (bon, la je suppute base sur mon experience, vu qu'il n'y a pas de domaine dans son exemple "en l'air", on peut pas reprocher de pas avoir analyse).
Regle de base de la programation objet: l'heritage coute trop cher pour ce qu'il rapporte, et les profs feraient bien d'arreter d'enseigner ca en premier quand ils abordent le sujet.
Regardez un framework comme Cocoa, vous aurez du mal a trouver qq chose qui descend plus bas que 2 niveaux, et on parle d'un framework UI vraiment complet. De meme chez Foundation, et meme Java, legendaire pour etre super complexe dans sa version ee, descends rarement a ce niveau dans sa version se (forte de qq milliers de classes, quand meme).
On ne le repetera jamais assez: wide and shallow, pas deep and narrow.
Sans avoir plus d'info que "c'est pour un jeu", et j'imagine un truc a la gta vu la diversite des vehicules existants:
Une interface Vehicule, avec assez peu de choses dedans (probablement une ou deux methods, pour faire bouger le machin).
Une classe concrete par vehicule. Probablement pas de classe abstraite, j'ai du mal a voir en quoi une voiture et une moto se comportent de facon similaire. Les differences un 4x4 et une twingo se modelisent par des donnees, pas de classes.
Une voiture volante, si tant qu'elle se comprte vraiment comme une voiture au sol rt comme un avion en l'air, serait une implementation de Vehicule qui compose une voiture et un avion.
Probleme resolu, et la meme solution te permet de faire une soucoupe roulante ou un avion sous marin si tu veux.
Ca implique evidemment que les classes soient fortement data driven, sinon ca marche pas terrible, et du coup on en revient au sujet principal, qui a effectivement l'air plus adapte pour ce genre de problematique, vu la flexibilite que ca apporte (apres, en pratique, j'en sais rien, je connais pas assez le sujet).