Problème d'héritage

Problème d'héritage - C++ - Programmation

Marsh Posté le 29-11-2002 à 18:14:14    

Salut...
 
J'ai une saleté de programme chiant à faire pour l'école. J'ai un problème de débutant qui me prend la tête depuis quelques heures. Alors je ravale ma fierté et je poste.
 
Voilà, j'ai 4 classes (pour le moment) dans mon programme :
 
MATRICE : encapsule tout ce qu'il faut pour faire des calculs sur des matrices.
 
MATRICE_INTERFACE : dérivée de MATRICE, permet d'afficher et de saisir les valeurs d'une matrice. Ces méthodes d'entrée/sortie étant liée à l'interface graphique, j'ai préféré les éloigner de ce qui concerne le calcul pur.
 
SEL : objet qui permet la résolution d'équations matricielles. Il utilise trois matrices déclarées ainsi : MATRICE *A, *B, *C.
 
SEL_INTERFACE : dérivée de SEL et y ajoute les méthodes d'entrée/sortie.
 
C'est là que j'ai un problème : je veux que SEL_INTERFACE gère des matrices de type MATRICE_INTERFACE pour pouvoir les afficher.
 
Seulement, si dans la déclaration de la classe SEL_INTERFACE je mets MATRICE_INTERFACE *A, *B, *C, je me retrouve avec 6 matrices : celles de SEL et celles de SEL_INTERFACE !
 
Si je décide de ne rien déclarer dans SEL_INTERFACE, alors j'ai bien les 3 matrices de SEL, mais je ne peux pas les afficher puisqu'elles sont de classe MATRICE.
 
Bien sûr, dans SEL_INTERFACE, faire A = SEL::A provoque une erreur... Mauvais transtypage.
 
Je ne veux pas déclarer les matrices de SEL en tant que MATRICE_INTERFACE sinon ça n'a plus de sens... Ce que je voudrais, c'est avoir 3 et seulement 3 matrices dans SEL comme dans SEL_INTERFACE, avec en plus la possibilité dans SEL_INTERFACE de pouvoir appeler les méthodes de MATRICE_INTERFACE.
 
La solution se trouve-t-elle du côté des méthodes virtuelles ?
 
Merci du coup de main...
 
Nehim, qui part s'acheter des lardons pour la tartiflette ce soir


Message édité par Nehim le 29-11-2002 à 19:18:23
Reply

Marsh Posté le 29-11-2002 à 18:14:14   

Reply

Marsh Posté le 29-11-2002 à 18:58:54    

ve pa critiqué mais tu voudrai pa coller tout le code, foutre les commentaires avec // et mettre en gras les lignes ou t'a des problemes de compilation ca serait plus lisibles

Reply

Marsh Posté le 29-11-2002 à 19:14:00    

Deja, tu devrais pas utiliser les balises "cpp" dans ton cas... Ca rends moins lisible.
 
Ben dans ta classe "SEL" (d'ailleurs pourquoi pas CSel, notation plus commune), tu peux stocker tes MATRICE_INTERFACE sous forme de MATRICE*.
Apres tu crees une fonction "virtual" dans "SEL" qui cree les bonnes MATRICE. Ex:
 

Code :
  1. class SEL
  2. {
  3. public:
  4. SEL()
  5. {
  6.   m_pMatrix = CreerMatrice();
  7. }
  8. ~SEL(){ delete m_pMatrix; }
  9. virtual MATRIX * CreerMatrice()=0;
  10. };
  11. class SEL_INTERFACE
  12. {
  13. public:
  14. MATRIX * CreerMatrice(){ return new MATRIX_INTERFACE; }
  15. };


 
Code incomplet et juste illutratif :-)


Message édité par kenshiro182 le 29-11-2002 à 19:27:37
Reply

Marsh Posté le 29-11-2002 à 19:20:22    

MrX a écrit a écrit :

ve pa critiqué mais tu voudrai pa coller tout le code, foutre les commentaires avec // et mettre en gras les lignes ou t'a des problemes de compilation ca serait plus lisibles




 
Désolé, j'ai cru bien faire avec les balises CPP, sans savoir que ça rendrait illisible (je m'attendais à un résultat du style de la balise HTML code). J'ai viré toutes les balises de mon message. Quant aux critiques, tu as le droit d'en faire bien sûr.
 
Nehim, newbe

Reply

Marsh Posté le 29-11-2002 à 19:33:25    

Ma solution est mauvaise, car la SEL_INTERFACE doit faire un cast de MATRIX vers MATRIX_INTERFACE ce qui est mal !
 
Il vaut mieux stocker les MATRIX_INTERFACE dans SEL_INTERFACE, et que SEL definisse une ou des méthodes pour accéder aux MATRIX:
 
virtual MATRIX* Matrix1()=0;
 
Ainsi quand SEL veut faire un calcul, il appelle Matrix1 et compagnie pour récuperer les MATRIX_INTERFACE.
 
D'ailleurs pourquoi faire une relation d'héritage entre SEL et SEL_INTERFACE ? Pourquoi SEL ne serait pas membre de SEL_INTERFACE ?
Si SEL_INTERFACE utilise  SEL, c'est la bonne solution. Je ne crois pas que SEL_INTERFACE soit  une sorte de  SEL...

Reply

Marsh Posté le 29-11-2002 à 19:43:03    

kenshiro182 a écrit a écrit :

Ben dans ta classe "SEL" (d'ailleurs pourquoi pas CSel, notation plus commune), tu peux stocker tes MATRICE_INTERFACE sous forme de MATRICE*.
Apres tu crees une fonction "virtual" dans "SEL" qui cree les bonnes MATRICE.



 
Pourquoi pas CSel ? En effet. Je ne connais pas encore les usages.
 
Si je comprends bien (intense concentration), tu me proposes de définir mes matrices dans SEL en tant que MATRICE *A, *B, *C;. Le constructeur de SEL s'occupe de l'appel de la fonction virtuelle idoine pour les créer avec le type voulu. Jusque là, je suis d'accord.
 
Toutefois, n'est-il pas besoin de les redéfinir dans SEL_INTERFACE ? Parce que le problème, c'est que mon compilateur ne veut pas de mes A->affiche() sous prétexte que A est a priori de type MATRICE* et pas MATRICE_INTERFACE*.
 
Ou alors, il me faudrait un moyen de forcer le compilateur à voir mes matrices comme des MATRICE_INTERFACE dans SEL_INTERFACE. On peut caster des classes ? Faire quelque chose comme (MATRICE_INTERFACE*)A->affiche() ?
 
Nehim, qui commence la préparation de la tartiflette

Reply

Marsh Posté le 29-11-2002 à 19:51:51    

kenshiro182 a écrit a écrit :

Ma solution est mauvaise, car la SEL_INTERFACE doit faire un cast de MATRIX vers MATRIX_INTERFACE ce qui est mal !



 
Nos posts se sont croisés et j'ai ma réponse pour le cast...
 
[citation]D'ailleurs pourquoi faire une relation d'héritage entre SEL et SEL_INTERFACE ? Pourquoi SEL ne serait pas membre de SEL_INTERFACE ?
 
Si SEL_INTERFACE utilise  SEL, c'est la bonne solution. Je ne crois pas que SEL_INTERFACE soit  une sorte de  SEL...[/citation]
 
Ben oui... C'est ce que j'avais fait avant et ça marchait plutôt bien ! Seulement, le prof voulait que cet exo nous serve d'apprentissage sur les objets. Malheureusement pour lui, l'analyse des besoins du programme révèle que la POO est complètement inutile. Tant pis pour lui...
 
Et merci pour tes éclaircissement. Je ne m'étais pas posé les bonnes questions, ça devrait aller mieux maintenant.
 
Nehim,
heureux d'avoir perdu plein d'heures pour de se coucher moins bête ce soir

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed