Discussion :

[pseudocode]

Donc carré hérite de rectangle et de losange.

L'héritage sert à "ajouter" des nouveaux comportements. Le LSP impose de ne pas modifier les comportements existants.

Un carré à plus de contraintes qu'un rectangle => un carré sait faire moins de chose qu'un rectangle. Donc la classe Carré n'hérite pas de la classe Rectangle.

En terme purement technique (conception orienté-objet), on pourrait faire l'inverse : la classe Rectangle hérite de la classe Carré. Mais ça n'aurait pas de sens du point de vue "métier" (sémantique) car un rectangle n'est pas une spécialisation d'un carré.

[chaplin]

c'est pire car il y a cette fois de nouveaux invariants relatifs à l'angle des côtés.

Je sais, mais c'était la condition sine qua none pour que la notion d'héritage est un sens.
Il ne s'agit pas non plus d'avoir une vue bridée sur les maths pour mettre en avant LSP. Là je m'aventure sur des charbons ardents .

J'aimerais quand même comprendre pourquoi, alors que l'article parle d'un diagramme qui met en avant les concepts de l'héritage, d'un point de vue OO LSP s'y oppose.

Ma question finalement, est ce que le sujet est réellement bien posé ?

Il y a quelque chose qui m'échappe, et c'est pour cela que j'ose relancer le débat.

L'héritage sert à "ajouter" des nouveaux comportements. Le LSP impose de ne pas modifier les comportements existants.

Au vu de l'énoncé, le carré hérite du comportement du rectangle et de celui du losange, cela dit losange et rectangle ont déjà en commun le comportement du parallèlogramme. Alors pourquoi C++ est le seul langage a accepté l'héritage multiple si déjà il l'autorise ?

Un carré à plus de contraintes qu'un rectangle => un carré sait faire moins de chose qu'un rectangle. Donc la classe Carré n'hérite pas de la classe Rectangle.

Entièrement d'accord, j'ai pas dit le contraire, quelqu'un en avait parlé.

Un carré à plus de contraintes qu'un rectangle => un carré sait faire moins de chose qu'un rectangle. Donc la classe Carré n'hérite pas de la classe Rectangle.

J'ai peut être la réponse, si je regarde l'énoncé, un rectangle est un quadrilatère avec 4 angles droits, il n'y a pas de restriction à mon sens par
rapport au rectangle puisque le carré a aussi 4 angles droits. En revanche il a 4 côté égaux, c'est à dire une caractèristique du losange
qui n'a rien à voir avec le rectangle. Cela ne change rien pour le calcul d'aire puisqu'on se reporte à la méthode de calcul définit par le parallèlogramme.

Le carré est un rectangle (4 angles droits) et un losange (4 côtés égaux).

[pseudocode]

Au vu de l'énoncé, le carré hérite du comportement du rectangle et de celui du losange, cela dit losange et rectangle ont déjà en commun le comportement du parallèlogramme. Alors pourquoi C++ est le seul langage a accepté l'héritage multiple si déjà il l'autorise ?

Non. Le carré "hérite" des CONTRAINTES du rectangle (a savoir 4 angles droits), mais pas du comportement (au sens service rendu).

Par exemple, un carré ne peut pas être utilisé pour modéliser un ecran d'ordinateur.

[souviron34]

je me re-permet d'intervenir sur ce sujet sur 2 points...

• Primo, toutes les descriptions de classes exposées dans cette discussion sont fausses, ou tout du moins incomplètes. Ce qui a été décrit correspond à un carré ou rectqngle de base horizontale. Comment décrivez-vous un carré posé sur la pointe (tourné de 45 degrés ou d'un angle quelconque) ? C'est pourtant bien un carré.
  
  
• Secondo, en ce qui concerne la discussion par rapport à l'héritage et l'OO plus précisément, et ses forces et faiblesses, je ré-itérerai ce que j'ai déjà dt sous une autre forme dans un autre débat : je crois que le fond des problèmes d'usage et de modélisation vient du langage technique et technocratique utilisé. Supprimez "classe", "héritage", "instance", et quelques autres, et écrivez en français.... Je crois que c'est le principal écueil rencontré. Bien qu'étant contre la méthode portant ce nom, je pense qu'il serait beaucoup plus clair d'enseigner et de penser en termes d'entités et de relations (les mots, pas la méthode ni ce qu'elle recouvre), ou si on veut d'objets et de propriétés, mais que la technicité impliquée par le langage fait perdre de vue le fond de l'analyse. Quand je vois les débats ici, ou que ce soit par rapports aux MCD, diagrammes, etc etc.. l'usage des mots come "classe" ou "instance" brouille, à mon sens, l'analyse de ce qui devrait être pensé. D'où les problèmes très bien démontrés par l'article pointé ci-dessus ou par cette discussion et d'autres.

[chaplin]

Primo, toutes les descriptions de classes exposées dans cette discussion sont fausses, ou tout du moins incomplètes.

Ah, descriptions de classes incomplètes, c'est ce qui m'a choqué.

Supprimez "classe", "héritage", "instance", et quelques autres, et écrivez en français.... Je crois que c'est le principal écueil rencontré

Si l'énoncé parle d'héritage, qu'est ce qui s'oppose à l'utiliser de façon litéral en OO ?

la technicité impliquée par le langage fait perdre de vue le fond de l'analyse

Ai-je bien réagi ou non ?

je crois que le fond des problèmes d'usage et de modélisation vient du langage technique et technocratique utilisé. Supprimez "classe", "héritage", "instance", et quelques autres, et écrivez en français.... Je crois que c'est le principal écueil rencontré. Bien qu'étant contre la méthode portant ce nom, je pense qu'il serait beaucoup plus clair d'enseigner et de penser en termes d'entités et de relations (les mots, pas la méthode ni ce qu'elle recouvre), ou si on veut d'objets et de propriétés, mais que la technicité impliquée par le langage fait perdre de vue le fond de l'analyse

D'où la réponse :

Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle

Bien qu'étant contre la méthode portant ce nom

Est-ce que vous sous entendez UML ?

D'où les problèmes très bien démontrés par l'article pointé ci-dessus

S'agit il de l'article que j'ai mis en lien ?

[Luc Hermitte]

Je sais, mais c'était la condition sine qua none pour que la notion d'héritage est un sens.

Mais qu'est-ce que l'héritage ? Un moyen d'importer du code comme on nous le vendait dans les années 80-90? Un moyen d'être utilisible en place d'autre chose ? Ou encore une autre notion ?

Il ne s'agit pas non plus d'avoir une vue bridée sur les maths pour mettre en avant LSP. Là je m'aventure sur des charbons ardents .

J'aimerais quand même comprendre pourquoi, alors que l'article parle d'un diagramme qui met en avant les concepts de l'héritage, d'un point de vue OO LSP s'y oppose.

Quel article? Il y en a eu un certains nombre de cités entre des articles de maths (et de rien d'autre), la démonstration de Robert C. Martin, les redites/traductions/...

Ma question finalement, est ce que le sujet est réellement bien posé ?

Je commence aussi à me le demander. On part d'un truc simple : expliquer le LSP avec un exemple contredisant notre intuition mathématique, et on se retrouve avec tout le monde qui cherche à produire une modélisation exploitant l'héritage (en vain si on veut lier directement carré et héritage)

Au vu de l'énoncé, le carré hérite du comportement du rectangle et de celui du losange, cela dit losange et rectangle ont déjà en commun le comportement du parallèlogramme.

Si vous voulez pinailler, toute la question est là :
- quel est le comportement de ces objets mathématiques (restons à des entités, et pas des valeurs pour que le débat ait un sens) ?
- quels sont les invariants de ces objets ?
- quels sont les pré- et post-conditions que l'on peut énoncer sur les comportements exposés ?

Robert C. Martin a définit deux familles de données (pour ne pas dire classes, instances,...)
- qui comme comportement permettent d'altérer la longueur de leurs côtés,
- avec les carrés qui ont pour invariant : les deux côtés ont la même longueur
- et il a supposé l'existence (le besoin par rapport à un métier fictif) d'une fonction complexe qui à un moment qui altère la largeur d'un rectangle, et attend de voir l'aire multipliée par le ratio de l'altération.

Et là ... avec héritage, plus rien ne marche. On ne peut pas passer une donnée carrée à cette fonction sans renoncer à un des deux contrats : soit on renonce à l'invariant de longueurs égales des carrés, soit on renonce à la post-condition sur la fonction.

Alors pourquoi C++ est le seul langage a accepté l'héritage multiple si déjà il l'autorise ?

Que nenni. C'est loin d'être le seul (de tête: Eiffel, Ruby ; probablement Smalltalk, objective-c, ...).
Te serais-tu laissé abusé par quelques langages mainstreams à la mode qui ne supportent qu'une forme bridée d'héritage multiple ?

[pseudocode]

[*]Primo, toutes les descriptions de classes exposées dans cette discussion sont fausses, ou tout du moins incomplètes. Ce qui a été décrit correspond à un carré ou rectqngle de base horizontale. Comment décrivez-vous un carré posé sur la pointe (tourné de 45 degrés ou d'un angle quelconque) ? C'est pourtant bien un carré.

? Un carré/rectangle a toujours sa base horizontale. Et il a aussi toujours sa base penchée de 45°. Et il a également toujours sa base penchée de 27.457842°. Ca dépend du repère. On n'a pas parlé de repèré ici.

je crois que le fond des problèmes d'usage et de modélisation vient du langage technique et technocratique utilisé. Supprimez "classe", "héritage", "instance", et quelques autres, et écrivez en français.... Je crois que c'est le principal écueil rencontré.

Ce n'est qu'un vocabulaire "commun" pour désigner des concepts. Il n'y a pas trop d'ambiguité sur ce que représente le concept de "classe" ou d' "heritage".

Pour moi, le problème est (comme toujours) de différencier la modélisation orienté-objet (métier) et la conception orienté-objet (code). Dans la plupart des méthode OO, on explique bien qu'il faut differencier l'analyse et la conception.

[chaplin]

On part d'un truc simple : expliquer le LSP avec un exemple contredisant notre intuition mathématique

Il y a l'intuition d'une part et la définition mathématique d'autre part.

Robert C. Martin a définit deux familles de données (pour ne pas dire classes, instances,...)
- qui comme comportement permettent d'altérer la longueur de leurs côtés,
- avec les carrés qui ont pour invariant : les deux côtés ont la même longueur
- et il a supposé l'existence (le besoin par rapport à un métier fictif) d'une fonction complexe qui à un moment qui altère la largeur d'un rectangle, et attend de voir l'aire multipliée par le ratio de l'altération.

Je trouve son exemple mal choisi parce qu'il suppose des choses, dans ce cas là il a effectivement raison! J'aimerais bien avoir l'avis d'un prof de math.

Et là ... avec héritage, plus rien ne marche

Exact, par rapport à ses satanées suppositions. Avec des oeillères, un cheval se laisse diriger par son maître.

Que nenni. C'est loin d'être le seul (de tête: Eiffel, Ruby ; probablement Smalltalk, objective-c, ...).
Te serais-tu laissé abusé par quelques langages mainstreams à la mode qui ne supportent qu'une forme bridée d'héritage multiple ?

Quit à me faire passer pour un imbécile, ça m'évite de chercher, j'ai au moins les réponses.

[souviron34]

Est-ce que vous sous entendez UML ?

Je ne sais pas, mais je ne crois pas. J'entends parler du modèle "entité-relation", et je ne fais justement pas référence à une méthode ou un formalisme particulier, mais au sens commun.

S'agit il de l'article que j'ai mis en lien ?

oui

? Un carré/rectangle a toujours sa base horizontale. Et il a aussi toujours sa base penchée de 45°. Et il a également toujours sa base penchée de 27.457842°. Ca dépend du repère. On n'a pas parlé de repèré ici.

Dans le même repère, si tu as un logiciel de dessin 2D qui trace des carrés, et qui te permet d'en tourner certains, comment les décriras-tu ?

Faut-il inventer une nouvelle classe de carrés ?

C'est la question que je pose. Le(s) modèle(s) donné(s) ne permet(tent) pas de représenter simplement la question générique : je ne veux pas attacher un repère à chaque carré, je veux représenter un carré quelconque dans un repère.

Ce n'est qu'un vocabulaire "commun" pour désigner des concepts. Il n'y a pas trop d'ambiguité sur ce que représente le concept de "classe" ou d' "heritage".

Pour moi, le problème est (comme toujours) de différencier la modélisation orienté-objet (métier) et la conception orienté-objet (code). Dans la plupart des méthode OO, on explique bien qu'il faut differencier l'analyse et la conception.

Visiblement ce message passe mal

Et même côté modélisation, je reviens sur le vocabulaire. Tu le sais comme moi avec l'algorithmie, quel que soit le langage qui sera utilisé, un bon algo est descriptible en bon français. Cela me sembleêtre la même chose pour la modélisation. L'usage de certains termes "restreint" la pensée et (à mon avis) oriente et "formatte" la réflexion et la modélisation. Si ce n'était pas le cas, cette discussion n'aurait pas donné lieu à +4 pages de discussions.

[Luc Hermitte]

Il y a l'intuition d'une part et la définition mathématique d'autre part.

La définition mathématique est statique. Il s'agit de valeurs immuables. Les exemples de R.C.Martin ont des comportements, il s'agit d'entités non immuables. À rapprocher de ce que l'on manipulerait dans des logiciels de dessin de schémas (xfig, powerpoint, visio, ...).

Je trouve son exemple mal choisi parce qu'il suppose des choses, dans ce cas là il a effectivement raison! J'aimerais bien avoir l'avis d'un prof de math.

Bien sûr qu'il suppose des choses. Tout est lié à ce contexte. Sors-en pour travailler sur des valeurs plutôt que des entités, et ... un carré pourrait tout à fait être un rectangle.
Il faut bien comprendre, que cet exemple n'est pas important. Il est juste volontairement choquant. Et j'ai l'impression qu'il détourne de la raison d'être de la démonstration. C'est pour cela que je préfère parler de Listes et de ListesTriées.

Et oui, en maths, on apprend bien qu'un carré est un rectangle. Mais en maths, la taille d'un carré, ou la longueur d'un rectangle ne changent pas. Dans le contexte de l'exemple de R.C.Martin, si.
Les quatre pages de discussion viennent en bonne partie de là.

[pseudocode]

C'est pas vraiment UML le problème. C'est le concept de UP (Process unifié).

Avec ce concept on a tendance a penser qu'il n'y a qu'une seule modélisation objet du début à la fin du projet (une classe d'analyse deviendra une classe de conception, qui deviendra une classe de code source). Or c'est faux.

On peut "modéliser" sous forme objet les besoins. On peut modéliser sous forme objet les exigences. Idem pour les données. Idem pour le code, ... Pour autant chacun des ces modèles est différent des autres. Le modèle objet des exigences (analyse) est différent du modèle objet des données (conception) qui est lui-même différent du modèle objet du code (implémentation).

Quand on dit que C++/Java/C# sont des langages "orientés-objets", on est ici dans le contexte très technique du langage de programmation = la plomberie. C'est à dire qu'on peut modéliser le CODE SOURCE sous forme objet.

Ca n'a aucun rapport avec la modélisation (objet ou non) des données, des exigences, ... On peut heureusement utiliser un langage OO avec une modélistation non objet, ou inversement.

Par chance, avec un langage OO, on peut assez souvent réutiliser (presque) le même modèle que la conception. Mais ce n'est ni obligatoire, ni toujours possible.

[chaplin]

Bien sûr qu'il suppose des choses. Tout est lié à ce contexte. Sors-en pour travailler sur des valeurs plutôt que des entités, et ... un carré pourrait tout à fait être un rectangle.

Luc , j'espérait ne pas me tapé l'article (par paresse) mais je l'ai lu en détail (11 pages). Il s'est servi d'un exemple bancal pour illustrer le LSP, parce qu'il a mal défini les règles au départ. Il a utilisé un SetWidth et SetLength dans le rectangle, ce qui est une erreur de conception car le carré est introduit après la définition du rectangle (et non dans une reflexion globale). Cela n'empèche pas de repartir sur des bonnes bases comme l'article que j'ai donné pour respecter les règles du LSP et implicitement de l'OCP. L'important est de rendre la modélisation compatible LSP donc prendre en compte dés le départ tous les scénarios et non en cours de route comme il l'a fait volontairement dans son article.

Je comprend en premier lieu (je me répète) de son article qu'il faut bien modélisé le problème et donc comprendre tous les aspects du problème dans les moindres détails (ie pour se conformer au LSP) avant de vouloir passé au codage. En fait, le LSP est un moyen préventif pour voir si le modèle objet est propre, une espèce de garde fou qui permet de juger de la qualité d'un code objet, comme dit l'auteur:

It is when this principle is in effect that applications are more maintainable, reusable and robust.

Donc, en se basant sur son exemple de rectangle, l'introduction du carré a montré que le modèle était foireux au départ (mal pensé), cela n'empèche de faire un modèle ou ça fonctionne. Qu'en pensez vous Souviron34 ?

[pseudocode]

Je comprend en premier lieu (je me répète) de son article qu'il faut bien modélisé le problème et donc comprendre tous les aspects du problème dans les moindres détails (ie pour se conformer au LSP) avant de vouloir passé au codage. En fait, le LSP est un moyen préventif pour voir si le modèle objet est propre, une espèce de garde fou qui permet de juger de la qualité d'un code objet

Oui pour ta 1ere phrase. Non pour la 2ème.

Il n'y a aucune bonne raison qu'une limitation de ton langage de programmation "remonte" dans la sémantique de tes concepts métiers. A part se simplifier la vie dans le codage, ce qui va ruiner les evolutions possibles de ton soft.

Au niveau ANALYSE: on modélise ce qui semble etre des contraintes géométriques => la classe Carré hérite de la classe Rectangle.

Au niveau CONCEPTION: on modélise des structures de données => Carré et Rectangle sont 2 classes distinctes avec leurs propres attributs et leurs propres traitements.

Au niveau CODE: avec un langage orienté-objet on peut (essayer de) réutiliser la modélistation de la conception, ou alors en créer une nouvelle.

[chaplin]

Je ne cherche pas à imposé un point de vue, je donne le mien, c'est l'interêt de ce débat d'échanger des points de vues. En tout cas je ne suis pas convaincu sur certains raisonnements, cependant il existe plusieurs approches pour résoudre le problème, héritage ou délégation/composition.
Mais l'échange riche de cette discussion va certainement permettre à chacun d'avoir une vision plus claire sur le fait que "le carré hérite du rectangle".

[hegros]

Mais l'échange riche de cette discussion va certainement permettre à chacun d'avoir une vision plus claire sur le fait que "le carré hérite du rectangle".

"le carré hérite du rectangle" n'est pas possible conceptuellement avec les termes employés usuellement en maths, en restant sur 1 dimension, un rectangle a une largeur et une longueur de ce fait comment un carré peut hériter de ces propriètés alors que pour un carré on parle de côté.

[chaplin]

en restant sur 1 dimension, un rectangle a une largeur et une longueur

, je ne comprend pas le sens de cette phrase. Comme j'avais fait la remarque à Luc Hermitte, l'héritage à un sens dans la mesure où on introduit quatre points ABCD d'un parallèlogramme, et si certains critères sont respectés, on parlera de rectangle, de losange ou de carré, sinon on reste à la dénomination parallèlogramme. Si on ne parle pas de ABCD, ça n'a pas de sens je suis d'accord.

Si je comprend bien le sens de la discussion. Quelqu'un a entendu un jour dans un cours que le carré hérite du rectangle, or il a constaté que tout le monde ne partageait pas le même avis, alors il a posé la question sur ce forum. Luc Hermitte est intervenu pour donner l'origine de la discussion, autrement dit il nous a expliqué pourquoi en cours on parlait du carré et du rectangle dans une relation d'héritage par rapport à un article de R.C.Martin sur les LSP.

D'ailleurs quand Luc Hermitte me fait cette remarque:

Bien sûr qu'il suppose des choses. Tout est lié à ce contexte. Sors-en pour travailler sur des valeurs plutôt que des entités, et ... un carré pourrait tout à fait être un rectangle.
Il faut bien comprendre, que cet exemple n'est pas important. Il est juste volontairement choquant. Et j'ai l'impression qu'il détourne de la raison d'être de la démonstration. C'est pour cela que je préfère parler de Listes et de ListesTriées.

En faisant quelque recherche sur internet, j'ai vu un exemple sur les oiseaux, qui est encore plus flagrant, où il démontrait que pingoin n'héritait pas d'oiseau parce qu'il ne vole pas alors que dans la classe abstraite été introduit la méthode Vole. On pourrait dire que c'est un raisonnement par l'absurde. Le seul but de ces exemples était de voir comment LSP montrait que le modèle objet tenait la route ou non (ie s'il était bien conçu ou non).

Après lecture d'articles et d'exemples pour illustrer la méthodologie de LSP, chaque exemple traité montre qu'il y a une erreur de conception au départ.
Donc LSP démontre les failles d'une conception quand elles existent, ces exemples ne sont que des illustrations, ce qui veut dire aussi qu'il ne faut pas prendre ces exemples pour des vérités.

[Luc Hermitte]

En cherchant à modéliser la nature selon un point de vue OO, on voit vite que ce n'est pas trop possible.

Sinon, le LSP n'est pas là pour montrer quand un modèle marche ou ne marche pas. Il exprime seulement une propriété qu'un modèle correct se doit de respecter.

[hegros]

, je ne comprend pas le sens de cette phrase.

oublie le 1 dimension. Quand tu vas au collége ou en primaire mais même au delà j'imagine usuellement on parle de largeur et de longueur pour un rectangle alors qu'on parle de côté pour un carré. D'ailleurs le périmétre d'un rectangle est exprimé par la formule l*L alors que pour le carré la formule est c*4.

Code :

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

1
2
3
4
class Rectangle
{
   int largeur, longueur;
}

Code :

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

1
2
3
4
5
class Carre
{
    int cote;
}

Voilà une implémentation possible qui respecte bien les termes usuels qui sont aussi des concepts de base.

On remarque assez aisément que l'héritage n'est pas une solution. On hériterait de largeur et longueur qui sont des concepts à priori inconnu dans un carré et qui sont d'autant d'aucune utilité ou redondant

[chaplin]

Le LSP est un principe parmis d'autres qui permet de valider une architecture orientée objet. Valider veut bien dire, ça ne marche ou pas. J'en perd mon latin

Quand tu vas au collége ou en primaire mais même au delà j'imagine usuellement on parle de largeur et de longueur pour un rectangle alors qu'on parle de côté pour un carré.

Justement hegros tu utilises le terme "usuellement", c'est une simplification pour faciliter le calcul d'aire, je parlerais même d'abus de langage. C'est bien pour cette raison que l'héritage marcherait si on parle des sommets ABCD où chaque point pourait être défini par des coordonnées (x,y), en revanche si ces sommets sont vus comme des propriétés, le principe d'encapsulation nous dit que les valeurs des sommets sont enregistrés dans des attibuts privés au travers de méthode set et get. Ces méthodes expriment le comportement d'une classe (behaviour).

[pseudocode]

Quelqu'un a entendu un jour dans un cours que le carré hérite du rectangle, or il a constaté que tout le monde ne partageait pas le même avis, alors il a posé la question sur ce forum.

Cela dépend de "quoi" tu hérites, et donc de ce que modélisent tes classes Rectangles et Carrés.

Si tes classes modélisent des contraintes géométriques, alors OUI, Carré hérite de Rectangle (tous les carrés ont "au moins" les memes contraintes que les rectangles).

Code java :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
class Quadrilatère {
  int nombreDeCote() { return 4; }
}
 
class Parallelogramme extends Quadrilatère {
  boolean PossèdeDesCotésParalleles2a2() { return true; }
}
 
class Rectangle extends Parallelogramme {
  int nombreAnglesDroits() { return 4; }
}
 
class Carré extends Rectangle {
  boolean possèdeQuatreCotésDeMemeLongueur() { return true; }
}

Si tes classes modélisent des positions ou des longueurs, alors NON, Carré n'hérite pas de Rectangle (car rien n'impose le respect des contraintes, à part le nom de la classe).