[fonctions virtuelles] appel de fonctions de la classe mere

Version imprimable

Voir 40 message(s) de cette discussion en une page

09/03/2007, 10h17
poukill

[fonctions virtuelles] appel de fonctions de la classe mere

(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 ! :D
09/03/2007, 10h32
Laurent Gomila

Citation:

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 ?
09/03/2007, 10h59
poukill

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! :D
09/03/2007, 11h40
Luc Hermitte

C'est louche. Tu parles de contenance et pourtant tu hérites.
09/03/2007, 13h14
poukill

Citation:

Envoyé par Luc Hermitte

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

J'ai parlé de contenance? 8O 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 :aie: ,
09/03/2007, 13h31
r0d

Pourquoi n'avez-vous pas opté pour un design de type "template method" ?
09/03/2007, 13h42
poukill

Citation:

Envoyé par r0d

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

Oui, on me l'a déjà conseillé dans le précédent topic que j'avais posté...
Je m'étais renseigner, mais je n'avais pas trouvé que ça changeait grand chose.

Après, j'ai peut-être mal compris ce Design... :aie:
Je pense acheter ce bouquin :

Citation:

Pour mieux développer avec C++

afin de mieux comprendre certains pattern...
09/03/2007, 14h13
Luc Hermitte

Citation:

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.
09/03/2007, 14h56
poukill

Citation:

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 ! :P
09/03/2007, 16h39
Jean-Marc.Bourguet

Citation:

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.

Citation:

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.

Citation:

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?
09/03/2007, 22h29
poukill

Je vais réfléchir...... Vous avez surement raison !! :oops:
10/03/2007, 23h53
Tijee

A mon avis ta conception n'est pas bonne...

Tu dois pouvoir faire autrement!
13/03/2007, 09h03
poukill

Citation:

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... :marteau:

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... :koi:

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

Merci à vous en tous cas pour votre aide ! :king:
14/03/2007, 02h00
nicroman

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.
14/03/2007, 03h01
Luc Hermitte

Pose le clavier. Prend un peu de bonne lecture (B.Meyer, Object Mentor, LSP, GOTW -- bien plus tard Coplien). Médite là.
Prends un papier, un crayon. Et demande-toi qui est susbtituable à quoi dans ta problématique. Qui est implémenté à partir de qui.

C'est une dichotomie basique qui guide les trois-quarts des design OO.
14/03/2007, 09h23
poukill

Citation:

Envoyé par Luc Hermitte

Pose le clavier. Prend un peu de bonne lecture (B.Meyer, Object Mentor, LSP, GOTW -- bien plus tard Coplien). Médite là.
Prends un papier, un crayon. Et demande-toi qui est susbtituable à quoi dans ta problématique. Qui est implémenté à partir de qui.

C'est une dichotomie basique qui guide les trois-quarts des design OO.

Ok Luc, je vais lire un peu... :idea:

J'ai fait le tour des critiques sur developpez.com et j'ai trouvé ces bouquins... Sachant que j'ai toujours des progrès à faire en C++ (gestion des exeptions absentes dans mon programme pour l'instant, etc.) et que j'ai aussi des progrès à faire en conception UML, je peux me décider à acheter deux livres, mais pas plus, hélas (budget un peu serré)

Pour l'instant, j'ai déjà le livre de Stroustrup en C++...

Parmis les 7 livres que j'ai noté ici qui semblaient correspondre à mes besoins, si je devais en prendre que 2, que me conseilleriez-vous?

1) Herb Sutter - Standard de programmation en C++
2)Aurélien Geron et Fatmé Tawbi - Pour mieux développez avec C++, design pattern, STL, RTTI et smart pointers
3) Scott Meyers - C++ efficace
4) Sinan Si Alhir - Introduction à UML
5) Craig Larman - UML 2 et les design Pattern
6) B. Meyer - Conception et Programmation Orienté Objet
7) Pascal Roques - UML 2 en action

Merci encore pour votre aide, un peu de "bonne lecture" me fera le plus grand bien...
J'attend vos suggestions, et je commande!

MERCI !8-)
14/03/2007, 20h13
poukill

J'ai négocié avec mon labo le budget pour acheter 2 livres, c'est bon... Donc j'ai moins de contraintes que je pensais...
Un ou plusieurs livres feront l'affaire (vu les lacunes, il faut les grands moyens !!)

J'attends vos suggestions.... :D
15/03/2007, 01h29
nicroman

B.Meyer est excellent.

Comme je disais dans un autre thread, oublies le C++ pour penser Objet. Le C++ n'est qu'un outil (language) d'implémentation qui peut être substitué par n'importe quoi (ou presque).
15/03/2007, 03h59
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.

3) Scott Meyers - C++ efficace
-> A priori très bien. Vise la 3ed. (j'ai le EC++ et le MEC++ de l'édition précédente)
Globalement un bouquin sur les "do and don't"

6) B. Meyer - Conception et Programmation Orienté Objet
-> Normalement très bien.
Si tu es dans un labo d'info et que des profs enseignent l'orientation objet, les plus sérieux auront déjà ce bouquin sur leurs étagères.
Un chapitre est dispo en "démo" comme je pensais l'avoir sous-entendu plus haut.

5) Craig Larman - UML 2 et les design Pattern
Je crois que j'avais acheté le premier. (UML pas 2), beaucoup de personnes semblent en être contentes. Mais je n'ai jamais fini de le lire, ni trouver le temps et l'intérêt pour le faire.

2)Aurélien Geron et Fatmé Tawbi - Pour mieux développez avec C++, design pattern, STL, RTTI et smart pointers
4) Sinan Si Alhir - Introduction à UML
7) Pascal Roques - UML 2 en action

Je n'en connais aucun.
15/03/2007, 09h31
poukill

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.

Citation:

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 ! 8-)

Voir 40 message(s) de cette discussion en une page