[Débutant] Héritage .

Version imprimable

Bonjour,

J'aimerais avoir quelques indications concernant l'héritage.
J'ai fait une classe Point qui modélise un point du plan :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
class Point{
protected:
        double x,y;
public:
       Point(double a=0., double b=0.) {
                    x=a;
                    y=b;
                    }
       Point( const Point & a)
       {
              x=a.x;
              y=a.y;
       }
       Point & operator =( const Point & a)
       {
              x=a.x;
              y=a.y;
              return * this;  
       }
 
       Point& deplace(double dx, double dy)
       {
             x=x+dx;
             y=y+dy;
             return *this;
       }                    
};

Et je voudrais faire maintenant une classe Vecteur3D qui hérite de la classe Point. Voici ce que j'ai fait pour l'instant :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
class Vecteur3D : public Point {
 
protected :
        double z;
public:
        Vecteur3D( double a=0, double b=0, double c=0 ){
            x=a;
            y=b;
            z=c;        
        }    
 
};

Je voudrais maintenant implémenter une méthode "deplace" qui permette de déplacer un vecteur selon le même principe que la méthode deplace() de la classe Point.
Pour cela j'ai fait la méthode suivante :

Code:

1
2
3
4
5
6
Vecteur3D& deplace(double dx, double dy, double dz)
        {
                   Point::deplace(dx,dy);
                   z=z+dz;
                   return *this;
                   }

Ce code compile et marche correctement.
Mais je me demande si c'est bien comme cela qu'il faut faire, et aussi je comprends pas pourquoi j'ai pas d'erreur de comilation si j'écris simplement :

Code:

1
2
3
4
5
Vecteur3D& deplace(double dx, double dy, double dz)
        {
                   Point::deplace(dx,dy);
                   z=z+dz;               
                   }

( j'ai enlevé le "*this" )

Merci.

11/02/2008, 16h14
befalimpertinent
:salut:

Tout d'abord un détail qui n'en n'ai pas un : essayes d'utiliser les listes d'initialisation dans tes constructeurs. Ainsi
Code:

1 2 3 4 5 6 7 8 9 Point(double a=0., double b=0.) { x=a; y=b; } Point( const Point & a) { x=a.x; y=a.y; }
devient
Code:

1 2 3 4 Point(double a=0., double b=0.): x(a), y(b) {} Point( const Point & a): x(a.x),y(b.y){} /*etc*/
Je te renvoie sur la FAQ pour plus de détails.

Sinon je ne vois pas le problème avec ton * this. La seule question à ce poser est : Est ce que deplace doit renvoyer l'Objet avec ses nouvelles coordonnées. A priori je dirais non mais rien ne t'en empêche et si cela t'es nécessaire au niveau de l'appelant pourquoi pas.
Enfin il n'est pas dis que faire hériter Vecteur3d de Point soit particulièrement judicieux. Sur du long terme en tout cas
11/02/2008, 17h40
JolyLoic
Citation:

Envoyé par rouliane

Je voudrais maintenant implémenter une méthode "deplace" qui permette de déplacer un vecteur selon le même principe que la méthode deplace() de la classe Point.

Je ne sais pas mathématiquement ce que signifie déplacer un vecteur... D'ailleurs, ce simple fait est un argument pour dire que vecteur ne devrait pas dériver de point.
Citation:
Envoyé par rouliane

je comprends pas pourquoi j'ai pas d'erreur de comilation si j'écris simplement :

Code:

1 2 3 4 5 Vecteur3D& deplace(double dx, double dy, double dz) { Point::deplace(dx,dy); z=z+dz; }

( j'ai enlevé le "*this" )
Je ne comprends pas non plus, ce code est faux, et devrait déclencher une erreur avec n'importe quel compilateur raisonnable (ou du moins un warning).
11/02/2008, 18h11
rouliane

Merci à vous deux !

Il va falloir que je m'y mette aux listes d'initialisation depuis le temps qu'on me le dit :oops:

Sinon, je suis d'accord avec vous pour dire que déplacer un vecteur veut pas dire grand chose, et je voyais pas non plus le but d'hériter de la classe Point, mais c'est un exercice, donc j'ai pas le choix :mrgreen:
11/02/2008, 18h26
screetch

veteur est un mauvais nom pour un point en 3D. tu dois confondre peut etre avec un vertex.

dans ce cas ca sent le probleme de conception a plein nez.

je ne pense pas que faire deriver le point 3D du point 2D soit vraiment correct. on utilise en general pour la derication un concept de "est un". en gros, lorsque A derive de B on dit que A "est un B". par exemple, un chat herite de la classe mammifere, et on dit que le chat "est un mammifere" et ca semble coller. on peut aussi se referer a d'autres exemples, comme le fait qu'une fenetre derive d'un widget, et "est un widget" que l'on peut dessiner.

mais un "point en 3D" n'est pas un point en 2D. enfin pas vraiment.
11/02/2008, 19h32
JolyLoic
Plus précisément (car être-un n'est pas très précis, après tout, un carré est-un rectangle au sens mathématique du terme...) :

Pour avoir B qui dérive de A, il faut que quel que soit le code valide qui travaille avec une instance de A (déjà construite, la construction elle peut varier), le code reste valide si on remplace A par B (c'est le LSP, principe de substitution de Liskov). Exemple avec une classe rectangle qui aurait une fonction setLargeur.
Code:

1 2 3 4 Rectangle r(10, 20); assert(r.hauteur() == 20); r.setLargeur(2); assert(r.hauteur() == 20);
Si on remplace par :
Code:

1 2 3 4 Carre c(20); assert(c.hauteur() == 20); c.setLargeur(2); assert(c.hauteur() == 20); // <- Va faire boom !
On voit bien que l'héritage carré dérive de rectangle n'est pas une bonne solution.

Dit autrement, pour chaque fonction, dans la classe dérivée, on peut uniquement être moins strict sur les pré-conditions, et plus strict sur les post-conditions (j'ai lu ça sous cette forme pour la première fois chez Meyers).
11/02/2008, 22h16
screetch

certes mais je trouve qu'on en etait pas encore arrivé la dans la discussion.

est un ou n'est pas un est une regle a comprendre pour savoir si l'heritage est une bonne idée...

de plus j'ai bien dit "en général" :)
11/02/2008, 22h47
Luc Hermitte

est-substituable / n'est-pas-substituable est pourtant le point autour duquel s'articule la dichotomie.
Mais bon, il est vrai que si le design est imposé ... nul besoin de l'encombrer avec cela pour l'instant.
12/02/2008, 08h38
poukill

D'autant plus que l'héritage est parfois utilisé pour une simple concordance de type (je pense au pattern décorateur).
Si c'est simplement un exercice, contentons nous de le guider vers la bonne voie ! ;)