[heritage] downcasting : une erreur de conception?

Version imprimable

01/03/2007, 08h31
poukill

1 pièce(s) jointe(s)

[heritage] downcasting : une erreur de conception?

Bonjour à tous !!!

J'ai un problème pas trop grave, mais que j'aimerai bien résoudre proprement!
Vous trouverez ci joint une partie de mon diagramme des classes...

CFP est une classe abstraite car la méthode setImageReferenceIR() ne peut pas être définie de la même manière dans toutes les classes filles. Celà m'arrange car de toute façon, je préfère que CFP soit non instanciable, même si elle a un sens ici...
Ma configuration est telle que setImageReferenceIR() possède la même implantation dans Antenne que dans HR. La seule différence est pour la classe LPT.

Mon projet concerne pour l'instant l'étude de phénomène physiques à l'aide des classes HR et Antenne, et pourra peut-etre à terme concerné la classe LPT.

Mon problème est le suivant:
J'ai pour l'instant implémenté des algorithmes dans la classe CFP qui marchent très bien pour Antenne et HR, mais pas pour LPT.
Etant donné qu'il y a qu'une seule petite fonction membre qui diffère, est ce que je pourrai pas "downcaster" setImageReferenceIR? Ou alors quis-je obliger de définir tous mes algorithmes dans chacunes des classes filles pour pouvoir bénéficier de setImageReferenceIR() ???

Merci à vous! :P
01/03/2007, 08h43
Mat007

Salut,

Je dirais que visiblement les algorithmes communs à Antenne et HR mais non à LPT ne devraient pas être factorisées dans CFP, qui regroupe les traitements communs à tous, mais dans une nouvelle classe située dans la hiérarchie entre CFP et Antenne/HR.

Au passage c'est un peu déstabilisant toutes ces abbréviations, même si je ne doute pas qu'elles fassent partie du langage du domaine :)

MAT.
01/03/2007, 08h56
poukill

Citation:

Envoyé par Mat007

Au passage c'est un peu déstabilisant toutes ces abbréviations, même si je ne doute pas qu'elles fassent partie du langage du domaine :)

MAT.

Oui, mais j'avais oublié de joindre le diagramme, ça t'aidait pas aussi !!!!:D
Ca fait parti du domaine, mais c'est mieux avec un diagramme des classes!!
01/03/2007, 14h40
Mat007

Ok donc non, en effet, je n'avais pas saisi que HR est un LPT (comme dans is a)...

Dans ce genre de situation la solution est souvent de mettre toutes les classes filles au même niveau, dans un premier temps en dupliquant les méthodes identiques, puis tout de suite après de factoriser les traitements communs petit à petit dans de nouvelles classes (éventuellement abstraites mais c'est pas obligé) juste au-dessus des classes filles qui dupliquent.
Au final il y a l'interface commune tout en haut et les classes filles tout en bas, et au milieu des classes dont le but est de factoriser les implémentations communes des classes filles.
La grosse difficulté consiste à trouver des noms adéquates pour toutes ces classes, c'est parfois loin d'être trivial ! :roll:

MAT.
02/03/2007, 09h16
poukill

Euh.. je vois bien ce que tu veux dire MAT, mais ma modélisation me plaît là car elle reflète vraiment la physique qui est derrière. On peut pas dire que ce soit grave de s'en éloigner, m'enfin bon...

Le truc qui est franchement bizarre dans mon cas ici, c'est que HR et Antenne ont vraiment le même type de comportement pour cette "méthode", alors que LPT n'a pas le même. De plus, HR est vraiment une partie de LPT!!!!
J'espère que vous me comprenez ! :aie:

Donc je sèche un peu là... ;)
02/03/2007, 09h35
Mat007

Citation:

Envoyé par poukill

De plus, HR est vraiment une partie de LPT!!!!

L'héritage a un sens très précis qui n'est a priori pas celui-ci si j'ai bien compris.
Si HR dérive de LPT c'est que HR est un LPT, dans le sens où partout où on utilise/parle de LPT on pourrait mettre un HR à la place.

Au fait ça signifie quoi LPT et HR ? :)

MAT.
02/03/2007, 09h50
poukill

HR est bien un LPT !!!!!!!!!!!!!!!!

Bon, je m'explique un peu plus pour que tu me comprennes! :mrgreen:

CFP = Composants Face au Plasma... Ce sont des composants physiques qui sont au contact du plasma. Cette classe générique n'est donc pas instanciable et tant mieux, les classes filles seront des composants précis à étudier...

Antenne = Une antenne de chauffage. Elle est surveillé par une caméra infrarouge

LPT = un composant de protection... Il ne ressemble pas du tout à une antenne. IL est aussi surveillé par une caméra infrarouge...
MAIS l'image infrarouge est constitué en deux images, deux parties différentes de LPT, l'un au dessus de l'autre... Les traitements ne doivent tenir compte que d'une seule partie de cette image, et c'est ce qui pose problème...

HR = Haute résolution. Abrévation de LPT HR, c'est la "moitié" du LPT observé par une caméra infrarouge plus performante encore. L'image infrarouge est constitué d'une seule image qui regarde en fait la moitié de ce que regarde le LPT...

Au final, HR est bien un LPT (même composant, même traitement à effectuer dessus). mais HR, comme Antenne ne possède qu'une seule image, contrairement au LPT!!!

Je persiste et je signe: ma modélisation est bonne, il y a juste ce setImageReferenceIR() qui est le même pour HR et Antenne (et c'est logique!)...
Mais je répère, c'est la seule fonction membre qui pose problème, pour le reste des traitements, HR se comportera vraiment comme LPT!

Merci pour ton aide MAT! ;)
02/03/2007, 09h52
r0d

Pour ce genre de problème, tu peux jeter un coup d'oeil sur le pattern "template method".

edit: correction, nos messages se sont croisés :)
02/03/2007, 10h36
poukill

Citation:

Envoyé par r0d

Pour ce genre de problème, tu peux jeter un coup d'oeil sur le pattern "template method".

edit: correction, nos messages se sont croisés :)

Je vais jeter un coup d'oeil... merci!
02/03/2007, 14h16
poukill
OK j'ai parcouru le forum et y ai trouvé plein de trucs intéressants... :D

Seulement, voilà. J'ai un gros doute sur un truc. Ca va peut-être paraître évident pour vous, mais bon...

La classe Mère :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 class Mere { public: Mere(); void fonction(); virtual void setImageReferenceIR() = 0; }; void Mere::fonction() { setImageReferenceIR(); }
La classe Fille1:
Code:

1 2 3 4 5 6 7 8 9 10 class Fille1 : public Mere{ public: Fille1(); virtual void setImageReferenceIR(); }; void Fille1::setImageReferenceIR() { //implémentation de la fonction qui va bien }
La classe Fille2:
Code:

1 2 3 4 5 6 7 8 9 10 class Fille2 : public Mere{ public: Fille2(); virtual void setImageReferenceIR(); }; void Fille2::setImageReferenceIR() { //implémentation de la fonction qui va bien }
C'est un ECM qui reproduit parfaitement mon problème: est ce que ce code est correct (ligne en rouge)??? Le polymorphisme permet-il celà?
Est-ce que ce code produit ce que je veux, i.e le programme choisit en fonction du contexte la fonction membre de fille1 ou bien de fille2 ?????

Merci beaucoup pour votre aide...:D
02/03/2007, 14h18
Médinoc

Le code serait correct si les filles étaient déclarées comme héritant de la classe Mère...
02/03/2007, 14h23
poukill

Citation:

Envoyé par Médinoc

Le code serait correct si les filles étaient déclarées comme héritant de la classe Mère...

:mrgreen: Corrigé!

Hum, ça veut dire que je n'ai pas besoin du pattern template method en fait?
:koi:
02/03/2007, 14h38
Jean-Marc.Bourguet

Citation:

Envoyé par poukill

C'est un ECM qui reproduit parfaitement mon problème: est ce que ce code est correct (ligne en rouge)??? Le polymorphisme permet-il celà?

Est-ce que ce code produit ce que je veux, i.e le programme choisit en fonction du contexte la fonction membre de fille1 ou bien de fille2 ?????

Oui... Sauf pendant l'exécution de constructeurs et de destructeurs: le type dynamique est alors considéré comme étant le type statique et il n'y a alors pas de dispatch.
02/03/2007, 14h43
poukill

Citation:

Envoyé par Jean-Marc.Bourguet

Oui... Sauf pendant l'execution de constructeurs et de destructeurs, le type dynamique est considere comme etant le type statique. Donc il n'y a alors pas de dispatch.

Alors mon problèmes est :resolu: !!! ^^

Merci à vous tous, comme d'habitude ! :yaisse2: