Discussion :

[David Fleury]

Bonjour,

dans http://www.objectmentor.com/resources/articles/lsp.pdf à propos du LSP, l'exemple est donné à base d'un Square héritant d'un Rectangle.

Auriez-vous une idée d'exemple qui poserait problème pour le cas d'un Rectangle héritant d'un Square ?

Cordialement.

[EDIT : Il semble que je ne sois pas dans la bonne section. Peut être faudrait-il déplacer mes post dans Algorithme ?]

[David Fleury]

Voici l'argument mis en avant dans l'article (en C++)

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
#include <iostream>

using namespace std;

class Rectangle
{
public:
  Rectangle( int w = 0, int h = 0 ) : width_(w), height_(h) {}
  
  virtual int width() const { return width_; }
  virtual int height() const { return height_; }

  virtual void width( int w ) { width_ = w; }
  virtual void height( int h ) { height_ = h; }
  
private:
  int width_;
  int height_;
};

class Square : public Rectangle
{
public:
  Square( int w = 0 )
  {
    width( w ); 
  }

  virtual void width( int w ) { Rectangle::width( w ); Rectangle::height( w );}
  virtual void height( int h ) {  Rectangle::width( h ); Rectangle::height( h ); }  
};

void g( Rectangle& r )
{
  r.width( 5 );
  r.height( 4 );
  
  assert( r.width() * r.height() == 20 );
}

int main()
{
  Rectangle r( 2, 3 );
  g( r );

  Square s( 4 );
  g( s );
}

Est-ce que celui là pour l'autre sens serait recevable ?

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
#include <iostream>

using namespace std;

class Square
{
public:
  Square( int w = 0 ) { width( w ); }
  
  int width() const { return width_; }
  void width( int w ) { width_ = w; }
  
  virtual double area() const { return width() * width(); }
  
private:
  int width_;
};

class Rectangle : public Square
{
public:
  Rectangle( int w = 0, int h = 0 )
  {
    width( w ); 
    height( h );
  }

  int height() const { return height_; }
  void height( int h ) {  height_ = h; }

  virtual double area() const { return width() * height(); }

private:
  int height_;
};

void g( Square& r )
{
  r.width( 5 );
  
  assert( r.area() == 25 );
}

int main()
{
  Square s( 4 );
  g( s );

  Rectangle r( 2, 3 );
  g( r );
}

[behess]

Il me semble plus logique qu'un carré hérite d'un rectangle, ce serait géométriquement plus juste... non ?

[David Fleury]

Malheureusement, je ne suis pas sûr que "géométriquement juste" soit un argument pour la modélisation dans mon cas.
L'article en question montre d'ailleurs que non.

J'ai cru comprendre que c'est un sujet délicat, ou tout le monde ne semble pas d'accord. En tout cas, l'essentiel est qu'une hiérarchie de classes répond à un besoin, et cette hiérarchie n'est valide que selon l'usage qu'on en fait. sa validité dépend du contexte.

[CinePhil]

Géométriquement, un carré est un rectangle particulier donc un carré hérite d'un rectangle, pas l'inverse !

À moins que vous ne vouliez remettre en question 3000 ans de géométrie ?

[gl]

Il y a déjà un long sujet à ce sujet sur le forum : Héritage classes carré/rectangle.

[CinePhil]

Je viens de lire la première page de la discussion et j'y ai "poucé" quelques messages.
Il y est notamment dit qu'on ne joue pas avec l'héritage "parce que c'est plus pratique" (un carré n'a qu'une propriété 'côté' donc c'est le rectangle qui hérite du carré parce qu'il lui faut 2 propriétés 'largeur' et 'longueur') mais qu'il faut d'abord modéliser des concepts réels et cohérents (un carré est un rectangle particulier).

J'ai l'impression que Hylvenir fait le même genre d'erreur en disant :

l'essentiel est qu'une hiérarchie de classes répond à un besoin, et cette hiérarchie n'est valide que selon l'usage qu'on en fait. sa validité dépend du contexte.

Comme je suis plus spécialiste de la modélisation pour les bases de données, je dis parfois à des intervenants des forums de modélisation ou des bases de données que ce n'est pas le programme qui doit commander la structure des données mais le programme qui doit s'adapter à cette structure.

Dans le programme, une classe "entreprise" aura par exemple et entre autres les propriétés "raison sociale", "numéro de siret", "code APE", "Adresse du siège social" Mais en base de données ces propriétés seront réparties dans plusieurs tables car une entreprise est une personne morale qui a en commun avec une personne physique la propriété "nom" et une "adresse principale" qui pour l'entreprise est celle du siège social et pour la personne physique celle de son domicile. À l'équipe de développement de demander au DBA de créer les vues adéquates pour que l'application puisse alimenter ses classes métier. L'ensemble de ces vues métier constitue ce que l'on appelle dans la méthode Merise le modèle organisationnel des données (MOD). Normalement, c'est seulement se modèle que devrait interroger tout programme mais bon nombre d'applications interrogent directement les tables de la BDD, ce qui peut poser problème en cas de changement du modèle de données.

Ma position reste inchangée : un carré est un rectangle particulier donc le carré hérite du rectangle.

[Richard_35]

Bonjour à tous,

Très intéressante discussion !...

Si nous modélisons les relations entre le carré et le rectangle, nous obtenons :

Code :

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

Carre -0,n---[Servir de base]---2,2- Rectangle

donnant :

Carre(DimensionCote, ...)
Rectangle(#DimensionCote, DimensionAutreCote) ==> trigger interdisant la création de plus de 2 rectangles à partir d'un carré

Il semble qu'il s'agisse d'un héritage un peu particulier car, en fait, le rectangle est une sorte d'association. Ce qui devrait donner :

Code :

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

Carre -0,n---[Générer rectangle]---0,n- AutreFormeGeometrique

donnant :

Carre(DimensionCote, ...)
AutreFormeGeometrique({propriétés identifiants de l'autre forme géométrique}, {autres propriétés de l'autre forme géométrique}, ... ) [I]
Rectangle(#DimensionCote, #{propriétés identifiants de l'autre forme géométrique}) ==> trigger interdisant la création de plus de 2 rectangles à partir d'un carré

Peut-être...

[CinePhil]

J'ai du mal à comprendre la signification de ton schéma.

Déjà, s'agit-il d'un diagramme de classes ou d'un MCD ?

Doit-on comprendre que tu considères qu'un rectangle est construit obligatoirement à partir de 2 carrés ?

Une feuille A4 est un rectangle. Plie là en 2. Obtiens-tu 2 carrés ?

[Richard_35]

Bonjour Philippe,

Déjà, s'agit-il d'un diagramme de classes ou d'un MCD ?

==> je ne sais ce qu'est un diagramme de classe, donc disons qu'il s'agit d'un MCD.

Il s'agit juste d'une base de réflexion, une tentative de modélisation des formes géométriques, dont le rectangle. Comme s'il n'existait aucune forme dans l'univers et qu'il faille les créer et les mettre en relation...

Doit-on comprendre que tu considères qu'un rectangle est construit obligatoirement à partir de 2 carrés ?

==> en quelque sorte, oui :

• un carré est identifié par une seule dimension = C (côté) ;
• un rectangle est identifié par deux dimensions = C1 et C2 (côtés), et il existe (conceptuellement, dans l'univers) deux carrés :
  
  • un carré de dimension C1 ;
  • un carré de dimension C2.

[CinePhil]

==> je ne sais ce qu'est un diagramme de classe, donc disons qu'il s'agit d'un MCD.

Ton association :

Carre -0,n---[Servir de base]---2,2- Rectangle

Traduction en français :
Un carré peut servir de base à plusieurs rectangles et un rectangle est basé sur deux carrés.

Doit-on comprendre que tu considères qu'un rectangle est construit obligatoirement à partir de 2 carrés ?

==> en quelque sorte, oui :

Il me semble avoir démontré que tout rectangle n'est pas défini à partir de seulement deux carrés !

Une feuille A4 est un rectangle. Plie là en 2. Obtiens-tu 2 carrés ?

Oserais-je dire que ça démontre par l'absurde que c'est bien le carré qui est un rectangle particulier et qui doit donc hériter du rectangle et pas l'inverse ?

Conceptuellement, et pour rester avec le MCD Merisien, le bon schéma est à mon avis celui-ci :
Carré -(1,1)----être----0,1- Rectangle -(1,1)----être------------0,1- Polygone
triangle_isocèle -(1,1)----être----0,1- triangle -(1.1)----être----0,1----|

On pourrait même mettre le quadrilatère et le parallélogramme entre le polygone et le rectangle.

[Davidbrcz]

Un carré ne doit hériter d'un rectangle.

Preuve : Supposons que carré hérite de rectangle.
Alors, selon le LSP, partout où on peut attendre rectangle, on peut passer un carré.

Considérons la fonction suivante (syntaxe C++ mais osef)

Code c++ :

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

1
2
3
4
5
6
7
 
void foo(rectangle& o) { 
rectangle* o2=o.clone(); 
o2.setLargeur(2*o.largeur());
assert(o2.aire()==2*o.aire()); //on vérifie que l'aire de o2 est le double de celle de o
delete o2;
}

Si on passe un carré à cette fonction, l'assertion final va échouer car en appelant setLargeur sur un carré, les deux cotés vont être impactés et l'aire multipliée par 4.

Bref, un carré n'est pas substituable à un rectangle. Il ne doit donc PAS en hériter. CQFD.

Un héritage inversé (rectangle qui hérite de carré) marcherait mais serait maladroit. Bref, pour moi le mieux ce de ne pas les faire hériter l'un de l'autre.

Edit: j'avais pas vu que je reprenais le même exemple que celui de l'article.

[Richard_35]

Philippe, tu utilises le rectangle et le carré en tant qu'objet matériel (ta feuille A4) !... Je tente de les utiliser en tant qu'objet conceptuel. En fait, la faute m'en incombe car j'ai mélangé les deux !...

Donc, restons dans un univers sans aucune forme existante. Cela donnerait :

Carre -2,n---[Servir de base]---2,2- Rectangle

==> un carré de coté C, sert de base à au moins 2 rectangles de côtés {C1,C2} :

• un rectangle de côtés {C,C2}, avec C2=de 1 point (objet conceptuel le plus petit) à n point (infini) ;
• un rectangle de côtés {C1,C}, avec C1=de 1 point (objet conceptuel le plus petit) à n point (infini).

Ceci, en considérant qu'un rectangle de 10x15 est différent d'un rectangle de 15x10 (mais nous pourrons y revenir plus tard, peut-être)
[ma réponse s'est croisée avec celle de Davidbrcz (que je salue) et la modification de CinePhil]

************

Sinon, en considérant qu'un rectangle de 10x15 est identique à un rectangle de 15x10, cela devrait donner :

Carre -1,n---[Servir de base]---1,2- Rectangle

donnant :

Carre(DimensionCote)
Rectangle(#DimensionCote, DimensionAutreCote)

Si je ne m'abuse...

[CinePhil]

C'est quand la conception s'éloigne de la réalité qu'elle aboutit à des aberrations de ce genre !

Dans la filiation Polygone - Quadrilatère - Parallélogramme - Rectangle - Carré, voilà comment on passe de l'un à l'autre :

Un polygone est une figure géométrique plane composée d'au moins trois segments de droite distincts.
Un quadrilatère est un polygone composé de 4 segments.
Un parallélogramme est un quadrilatère qui a ses segments parallèles deux à deux.
Un rectangle est un parallélogramme qui a 4 angles droits.
Un carré est un rectangle qui a ses 4 segments égaux.

Preuve : Supposons que carré hérite de rectangle.
Alors, selon le LSP, partout où on peut attendre rectangle, on peut passer un carré.

Si on passe un carré à cette fonction, l'assertion final va échouer car en appelant setLargeur sur un carré, les deux cotés vont être impactés et l'aire multipliée par 4.

Si on suit le même raisonnement en remontant d'un étage, essaie d'appliquer ta formule à un quadrilatère convexe quelconque qui n'est pas un parallélogramme, par exemple dont les côtés A, B, C, D mesurent respectivement 5, 3, 4 et 1.
Déjà, comment définir la larguer d'un tel quadrilatère ?

[Richard_35]

C'est quand la conception s'éloigne de la réalité qu'elle aboutit à des aberrations de ce genre !

==> à quelle aberration fais-tu référence ?

Effectivement, parlons de segment qui, en fait, est l'unité de base :

Code :

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

1
2
Segment -1,n---[Etre propriété]---1,1- Carré
   |-----1,n---[Etre propriété]---2,2- Rectangle

donnant :

Segment(NombrePoint)==> 1 segment est identifié de manière unique par un nombre de point(s) (unité mathématique de base)
Carré(#NombrePoint)==> 1 carré est identifié de manière unique par 1 segment
Rectangle(#NombrePoint, #NombrePoint2)==> 1 rectangle est identifié de manière unique par 2 segments différents

Exemple concret :

• le segment de 10mm d'1 carré sert de base à des rectangles dont 1 des segments est de 10mm et l'autre de >0 mm à l'infini (sauf 10mm, sinon ce serait un carré , ce qui tend à penser que le carré est un rectangle particulier) ;
• les segments de 15mm et de 20mm d'un rectangle, correspondent à des carrés de 15mm x 15mm et à des carrés de 20mm x 20mm (2 et seulement 2).

[CinePhil]

les segments de 15mm et de 20mm d'un rectangle, correspondent à des carrés de 15mm x 15mm et à des carrés de 20mm x 20mm (2 et seulement 2).

Euh...

Ton rectangle fait 15mm x 20mm et tu le dessines avec 2 carrés de 15 x 15 et 2 carrés de 20 x 20 ?

Remontons encore d'un niveau : un segment est défini par deux points distincts.
Point -0,n----définir----2,2- Segment

Point (pt_id, pt_coord_x, pt_coord_y)
Segment (sgt_id, sgt_id_point_1, sgt_id_point_2)
=> Contrainte : sgt_id_point_1 <> sgt_id_point_2

Un polygone est défini par 3 segments et plus.

Segment -0,n----définir----3,n- Polygone

Polygone (plg_id...)
plg_definir_sgt (pds_id_polygone, pds_id_segment)
=> Contrainte : 3 segments au moins pour chaque polygone.

Un quadrilatère est un polygone à 4 côtés.

Quadrilatere -(1,1)----être----0,1- Polygone

Quadrilatere (qdr_id_polygone...)
=> Contrainte : 4 instances de qdr_id_polygone dans plg_definir_sgt
=> Dans une classe Quadrilatere, je peux déjà définir une fonction calculerAire.

Aire : l'aire d'un quadrilatère convexe est égale au demi-produit des diagonales multiplié par le sinus de l'angle qu'elles forment (l'angle utilisé étant le plus petit des deux angles formés par les droites).

Un parallélogramme est un quadrilatère dont les côtés sopnt parallèles deux à deux.

Parallelogramme -(1,1)----être----0,1- Quadrilatere

Parallelogramme (prl_id_quadrilatere...)
=> Contrainte : vérifier le parallélisme des côtés deux à deux.
=> La fonction calculerAire fonctionne pour un parallélogramme mais je peux la surcharger pour la simplifier.

Un rectangle est un parallélogramme qui a 4 angles droits.

rectangle -(1,1)----être----0,1- parallélogramme

Rectangle (rec_id_parallelogramme...)
=> Contrainte : vérifier que les angles entre deux segments consécutifs sont tous de 90°.
=> Là encore, je peux surcharger la fonction calculerAire.
=> Le calcul des angles peut être une fonction du polygone et je peux encore l'utiliser ici pour vérifier mes angles.

Un carré est un rectangle qui a 4 côtés égaux.

Carre -(1,1)----être----0,1- rectangle

Carre (car_id_rectangle...)
=> Là encore, je peux surcharger la fonction calculerAire.
=> Le calcul de la longueur du segment est une fonction de la classe Segment. On l'utilise pour vérifier que les 4 longueurs sont égales.

[Richard_35]

Phrase ambiguë, en effet.

Donc, les segments de 15mm et de 20mm d'un rectangle, correspondent à 1 et 1 seul carré (15mm x 15mm) et à 1 et 1 seul carré (20mm x 20mm) : 2 carrés et seulement 2 carrés sont "concernés" par un rectangle.

[David Fleury]

J'ai l'impression que Hylvenir fait le même genre d'erreur en disant :


Comme je suis plus spécialiste de la modélisation pour les bases de données, je dis parfois à des intervenants des forums de modélisation ou des bases de données que ce n'est pas le programme qui doit commander la structure des données mais le programme qui doit s'adapter à cette structure.

Sauf erreur, ce n'est pas ma conclusion, mais celle de l'article dont l'auteur semble être un spécialiste de la conception objet.

Ma position reste inchangée : un carré est un rectangle particulier donc le carré hérite du rectangle.

L'article décrit pourquoi, dans point de vue LSP, ça ne peut être le cas.
tout en donnant un exemple qui ne fonctionne pas.

Et j'essaye aussi de donner un exemple pourquoi l'autre sens ne fonctionne pas.
Il semble de toute façon (je vais aller voir le fil de discussion donné), la validité d'une hiérarchie de classe n'a de sens que par les pré/post conditions définies.
Si non définies, on peut plus facilement "casser" la validité d'un héritage.

[CinePhil]

Phrase ambiguë, en effet.

Donc, les segments de 15mm et de 20mm d'un rectangle, correspondent à 1 et 1 seul carré (15mm x 15mm) et à 1 et 1 seul carré (20mm x 20mm) : 2 carrés et seulement 2 carrés sont "concernés" par un rectangle.

Idem : Comment dessines-tu un rectangle avec un carré de 15 x 15 et un carré de 20 x 20 ?

[David Fleury]

Il y a déjà un long sujet à ce sujet sur le forum : Héritage classes carré/rectangle.

Merci pour le lien.
On peut y trouver des choses intéressantes.