[fonctions virtuelles] appel de fonctions de la classe mere

**poukill** · 09/03/2007, 10h17

(re) bonjour à tous!
Suite à la discussion lancée par moi-même : http://www.developpez.net/forums/sho...64&postcount=1
J'aimerai avoir votre avis sur le type de comportement à mettre dans ce cas un peu particulier d'héritage:

J'ai la classe C qui dérive de la classe B, qui elle même dérive de A (abstraite)

La fonction membre A::test() ne convenant pas dans C, il faut la réimplémenter : B::test().
Par contre, pour ma classe C, l'implémentation de la classe mère A est correcte.

Y a t-il un choix judicieux à faire? i.e. déclarer test() comme virtuelle, virtuelle pure, ou bien ne rien déclarer du tout? La fonction test() utilisée dans la classe C pourrait elle naturellement appeler la fonction membre déclarer dans la classe mère abstraite A???

Encore merci pour vos réponses !

**Laurent Gomila** · 09/03/2007, 10h32

La fonction test() utilisée dans la classe C pourrait elle naturellement appeler la fonction membre déclarer dans la classe mère abstraite A???

Oui. Mais bon ça paraît bizarre comme situation. Tu peux expliquer un peu pourquoi le comportement par défaut n'est pas bon dans B mais l'est dans C ?

**poukill** · 09/03/2007, 10h59

Oui bien sûr...
Une bonne partie de l'explication est sur http://www.developpez.net/forums/sho...d.php?t=287988

J'ai deux classes qui dérivent de A en fait, comme sur le diagramme des classes joint au post ci dessus...
En gros, la classe C est une partie de la classe B... Tout est pareil, sauf que la classe n'est consituée que d'une seule image infrarouge, alors que B de deux images infrarouges.... (cf post ci précedemment cité)

Cette modélisation est mûrement réféchie, et je pense correcte!

**Luc Hermitte** · 09/03/2007, 11h40

C'est louche. Tu parles de contenance et pourtant tu hérites.

**poukill** · 09/03/2007, 13h14

Envoyé par Luc Hermitte

C'est louche. Tu parles de contenance et pourtant tu hérites.

J'ai parlé de contenance?

Tu dois surement avoir raison, mais je vois pas ce quoi tu parles...

Sinon, mon problème pourrait se résumer ainsi :
Soit trois classes A B, et C(classe mère). B est une classe extrement voisine de la classe A. Tous les traitements valables pour A sont valables pour B, exepté setImageReferenceIR() qui est diffénte dans B.
Deux choix s'offrent à nous:
*Mettre les classes A et B sur le même plan, toutes les deux héritant de C. Ils faudra implémenter toutes les méthodes dans chaqune de ces classes.
*Faire hériter B de A, et réécrire la méthode setImageReferenceIR() uniquement.

J'espère avoir été clair

,

**r0d** · 09/03/2007, 13h31

Pourquoi n'avez-vous pas opté pour un design de type "template method" ?

**Luc Hermitte** · 09/03/2007, 14h13

Envoyé par poukill

Tout est pareil, sauf que la classe n'est consituée que d'une seule image infrarouge, alors que B de deux images infrarouges....

Pour moi, c'est là que tu parles de contenance. Je peux me tromper.
Je ne vois pas comment un truc qui dérive peut avoir moins que ce dont il dérive. Cela me parait guère substituable, donc sujet à dérivation (publique).

Si tu ne vois pas ce à quoi je fais allusion, sur object mentor tu as des articles sur le LSP et sur comme quoi les carrés ne sont pas des rectangles.

**poukill** · 09/03/2007, 14h56

Envoyé par Luc Hermitte

Pour moi, c'est là que tu parles de contenance. Je peux me tromper.
Je ne vois pas comment un truc qui dérive peut avoir moins que ce dont il dérive. Cela me parait guère substituable, donc sujet à dérivation (publique).

Si tu ne vois pas ce à quoi je fais allusion, sur object mentor tu as des articles sur le LSP et sur comme quoi les carrés ne sont pas des rectangles.

Je suis embêté Luc, tu est en train de me montrer que j'ai tort

Plus sérieusement, B possède deux images infrarouges, alors que A une seule. C'est ce que j'ai dit...
Maintenant, la réalité est la suivante :
L'objet A est vu par une caméra infrarouge à deux CCD (2 secteurs de 30°)
L'objet B est vu par une caméra infrarouge à deux CCD aussi (1 secteur de 30° en haute résolution)
Donc en fait l'objet B est la moitié de l'objet A (on ne voit qu'un secteur, mais "zoomé" )

C'est bien un mécanisme d'héritage pour moi à mettre en oeuvre, car B est une partie de A! Juste qu'ici, tout va bien. Le problème c'est que les physiciens font l'analyse d'un seul secteur à la fois : je ne dois prendre en compte dans mes calculs qu'un seul des 2 secteurs pour l'objet A.

Mis à part cette fonction membre à implémenter différemment, les objets A et B sont les mêmes, une fois que j'ai pris la "moitié de l'objet A".
Mais B est bien une conséquence de A...

Ton avis m'intéresse beaucoup Luc,

Merci à tous pour votre aide !

**Jean-Marc.Bourguet** · 09/03/2007, 16h39

Envoyé par poukill

Je suis embêté Luc, tu est en train de me montrer que j'ai tort

Et je crains qu'il n'ait raison.

C'est bien un mécanisme d'héritage pour moi à mettre en oeuvre, car B est une partie de A!

Si B est une partie de A, A doit contenir un B, pas B heriter de A.

Juste qu'ici, tout va bien. Le problème c'est que les physiciens font l'analyse d'un seul secteur à la fois : je ne dois prendre en compte dans mes calculs qu'un seul des 2 secteurs pour l'objet A.

Introduire une classe secteur?

**poukill** · 13/03/2007, 09h03

Envoyé par Luc Hermitte

Pour moi, c'est là que tu parles de contenance. Je peux me tromper.
Je ne vois pas comment un truc qui dérive peut avoir moins que ce dont il dérive. Cela me parait guère substituable, donc sujet à dérivation (publique).

Hum... Tu as raison Luc.
L'inverse serait bien entendu beaucoup plus logique...

Le truc, c'est qu'au début de mon projet, je n'avais que deux classes (Antenne et LPT), toutes les deux dérivant de ma classe mère abstraite.
Depuis, une nouvelle caméra haute résolution est installé, alors j'ai rajouté cette classe LPT_HR (que j'ai juste appelé HR ) HR = Haute Résolution

Dans ce cas là, que faut-il faire? Remodifier la conception pour faire hériter LPT de HR? Ma conception était mauvaise, car pas assez "robuste"?
Ca m'embête d'admettre que ma conception est pourrie, car j'y ai passé du temps, beaucoup de temps...

Alors, dites moi... Je vous écoute. Je suis prêt à recoder s'il le faut ! ^^

Merci à vous en tous cas pour votre aide !

**nicroman** · 14/03/2007, 02h00

Il n'y a qu'une grande règle à l'héritage: B hérite de A si et seulement si tout objet B EST UN A.

Donc si HR hérite de LPT, ca veut dire que tout HR est un LPT....

Pour se ramener au code, imagines le code utilisateur de tes objets... Un bout de code qui prend un LPT en entrée doit toujours fonctionner avec un HR, puisque LPT en hérite ! Donc tout HR est un LPT.

**poukill** · 15/03/2007, 09h31

Ok merci à vous deux...
J'ai commandé pour l'instant :

1)Herb Sutter/ Andrei Alexandrescu - Standard de programmation en C++
2)B. Meyer - Conception et Programmation Orienté Objet
3)Design Patterns Tête la première

Ca, c'est fait.

Envoyé par Luc Hermitte

1) Herb Sutter/ Andrei Alexandrescu - Standard de programmation en C++
-> Très bien. Mais il y a peut être d'autres choses à connaitre avant -- genre AC++. Je ne sais pas s'il est immédiatement pertinent.

Je ne suis pas sûr de comprendre ce que tu veux dire. Quelle choses à connaître avant?
Le commentaire de bigboomshakala n'en fait pas vraiment mention :http://c.developpez.com/livres/#L2744071447
Donc si tu pouvais t'expliquer un peu plus, ce serait sympa.

Merci !

**Luc Hermitte** · 15/03/2007, 12h15

Le genre de choses à connaitre avant ?
Le C++

Le truc est que je ne sais pas s'il convient à des nouveaux arrivés. Ceci dit, il explique des choses importantes que tu ne trouveras dans aucun cours.
Donc, je ne sais pas.

**Jean-Marc.Bourguet** · 15/03/2007, 12h39

Envoyé par Luc Hermitte

Le genre de choses à connaitre avant ?
Le C++

Le C++ efficace est à mon avis à lire avant.

Le truc est que je ne sais pas s'il convient à des nouveaux arrivés. Ceci dit, il explique des choses importantes que tu ne trouveras dans aucun cours.
Donc, je ne sais pas.

C'est un livre bizarre que je n'ai pas apprécié beaucoup. Le titre est d'une part de nature à induire en erreur, d'autre part, il mélange des conseils de plusieurs natures sans préciser justement la nature, ce qui fait que certaines choses peuvent être aisément mal comprises. Il faudrait que je le reprenne
pour pouvoir être explicite (mais comme je ne l'ai pas acheté, il faudrait que je m'assure qu'il est toujours au boulot... la dernière fois que je l'ai vu il était sur le bureau d'un collègue qui a changé de site, il n'est pas impossible qu'il l'ai emporté)

**poukill** · 15/03/2007, 13h41

Envoyé par Luc Hermitte

Le genre de choses à connaitre avant ?
Le C++

J'ai déjà quelques bases en C++ quand même

S'il n'y a que ça, je peux commander aussi le C++ efficace. La dernière version (3ème édition) est en Anglais. Ca ne me pose pas vraiment problème, mais quand y'a pas mal de trucs à défricher, en français c'est bien aussi!

Quelle version faudrait-il privilégier?

**Jean-Marc.Bourguet** · 15/03/2007, 14h34

Envoyé par poukill

J'ai déjà quelques bases en C++ quand même

S'il n'y a que ça, je peux commander aussi le C++ efficace. La dernière version (3ème édition) est en Anglais. Ca ne me pose pas vraiment problème, mais quand y'a pas mal de trucs à défricher, en français c'est bien aussi!

Quelle version faudrait-il privilégier?

La dernière. Il a ajouté des choses, mis à jour d'autres et enlevé certaines qui n'avaient plus qu'un intérêt historique.