Discussion :

[rouliane]

Bonjour,

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[befalimpertinent]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[JolyLoic]

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.

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[rouliane]

Merci à vous deux !

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

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

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

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

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Rectangle r(10, 20);
assert(r.hauteur() == 20);
r.setLargeur(2);
assert(r.hauteur() == 20);

Si on remplace par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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