Tableau et Classes dérivées

**Minisurfeur17** · 19/04/2007, 11h44

Bonjour à tous je suis nouveau sur le forum et je me suis inscrit pour essayer de trouver une solution à un problème.

Je suis actuellement en IUT Informatique et je dois réaliser un projet (libre) en binôme et en c++.Nous avons choisi de faire un "Super puzzle fighter-like" en utilisant la librairie Allegro.
(un lien pour voir le principe du jeu: http://www.playfrance.com/news-video...-hd-remix.html)

Notre projet est déjà assez avancé et nous avions décidé d'utiliser un tableau 2d c++ pour gérer des pointeurs de briques,le tableau représentant la surface de jeu.
Nous avions donc une seule classe Brique avec un attribut "type" pour différencier les différents types de briques.(3 au total)

Seulement notre prof( après une première démonstration) nous a demandé de faire des classes dérivées pour chaque type de brique.

Mes questions sont donc les suivantes :y'a t'il un moyen d' utiliser le tableau de la même manière qu'avant le changement de conception? (sachant que nous avons déjà ecrit un grand nombre de fonctions utilisant le tableau et le type dans la Brique)

le seul moyen (hypothétique) que j'ai trouvé mais qui ne me satisfait pas vraiment est de faire 3 classes dérivées les unes par rapport aux autres et de faire un tableau contenant des pointeurs de la classe la plus dérivée (qui pourrait du coup aussi pointer vers des objets de classes moins dérivées).

Je veux en fait savoir si il vaut mieux tout reprendre à zéro à cause de ce changement de conception où si il y'a un moyen de s'en sortir sans trop de "bidouillages".

J'espère avoir été assez clair même si c'est difficile de tout expliquer quand on a le nez dans son projet, et je remercie d'avance toutes les personnes qui prendront le temps de me lire voire de me répondre.

**Ksempac** · 19/04/2007, 12h01

Bienvenue,

le seul moyen (hypothétique) que j'ai trouvé mais qui ne me satisfait pas vraiment est de faire 3 classes dérivées les unes par rapport aux autres et de faire un tableau contenant des pointeurs de la classe la plus dérivée (qui pourrait du coup aussi pointer vers des objets de classes moins dérivées).

Ce que tu racontes est un peu confus, mais je pense que tu es en train de te tromper.

Une instance d'une classe dérivée peut se faire passer pour une instance de la classe mere mais pas le contraire.

En consequence voila comment faire :

Une classe mere : Brique qui contient des methodes virtuelles

3 classes filles qui redéfinissent les méthodes de la classe mére (polymorphisme):
Brique1 dérive de Brique
Brique2 dérive de Brique
Brique3 dérive de Brique

Ensuite ton tableau reste un tableau de Brique* qui appellent les méthodes connues de tous et donc idéalement tu n'as pas besoin de savoir quel est le véritable type de ta brique. Si a un moment tu as besoin de savoir a quelle classe dérivée tu as affaire, il suffira d'utiliser dynamic_cast

**Minisurfeur17** · 19/04/2007, 12h14

Envoyé par Ksempac

Bienvenue,

Une instance d'une classe dérivée peut se faire passer pour une instance de la classe mere mais pas le contraire.

Je l'avais bien compris dans ce sens la mais j'ai eu en effet du mal à l'exprimer..

Dans ton exemple la Classe mère est-elle purement virtuelle ?(ou cela n'a -til aucune importance?) Est-ce que je pourrais accéder à toutes les fonctions et attributs des briques dérivées une fois qu'elles seront dans le tableau?

Sinon merci pour le dynamic_cast je ne connaissais pas mais je vais faire des recherches c'est exactement ce qu'il me faut.Et merci pour ta réponse claire et rapide!

**poukill** · 19/04/2007, 13h56

Parfois, revoir la conception n'est pas forcément repartir de zéro!!!
Certes, ça fait changer complétement son fusil d'épaule, mais c'est pour le bien de ton application!
-> voir modularité sur

!!!

**Minisurfeur17** · 19/04/2007, 14h29

Envoyé par poukill

-> voir modularité sur

!!!

c'est très interessant comme notion et c'est sur que je ne vais pas complètement repartir de zero vu que je sais déjà comment implanter les fonctionnalités de mon projet (du moins dans les grandes lignes) avec le travail que j'ai fait précedemment. C'est plus de la réadaptation...
Sinon est-ce quelqu'un pourrait m'éclaircir sur mes deux questions précedentes avant que j'attaque vraiment le changement?

Dans ton exemple la Classe mère est-elle purement virtuelle ?(ou cela n'a -til aucune importance?) Est-ce que je pourrais accéder à toutes les fonctions et attributs des briques dérivées une fois qu'elles seront dans le tableau?

**Laurent Gomila** · 19/04/2007, 14h32

Dans ton exemple la Classe mère est-elle purement virtuelle ?(ou cela n'a -til aucune importance?)

Ca n'a aucune importance.

Est-ce que je pourrais accéder à toutes les fonctions et attributs des briques dérivées une fois qu'elles seront dans le tableau?

Avec un dynamic_cast (pour peu que tu connaisses le type dérivé), mais le but est justement d'éviter ça. Normalement tu devrais pouvoir t'en tirer avec les fonctions virtuelles uniquement, sans connaître le détails des classes dérivées.

**Minisurfeur17** · 19/04/2007, 15h12

Avec un dynamic_cast (pour peu que tu connaisses le type dérivé), mais le but est justement d'éviter ça. Normalement tu devrais pouvoir t'en tirer avec les fonctions virtuelles uniquement, sans connaître le détails des classes dérivées.

d'accord donc pour accéder aux attributs j'utilise juste des accesseurs ?

**poukill** · 19/04/2007, 15h22

Oui
C'est le principe du polymorphisme : posséder une référence, un pointeur vers une instance de classe assez générale. Avec ce pointeur, tu vas manipuler en fait une classe dérivée, qui est le "vrai" objet en question.