Discussion :

[poukill]

(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]

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]

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]

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

[poukill]

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]

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

[poukill]

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...
Je pense acheter ce bouquin :

Pour mieux développer avec C++

afin de mieux comprendre certains pattern...

[Luc Hermitte]

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]

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]

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]

Je vais réfléchir...... Vous avez surement raison !!

[Tijee]

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

Tu dois pouvoir faire autrement!

[poukill]

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]

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.

[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.

[poukill]

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

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 !

[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....

[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).

[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.

[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.

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 !