Discussion :

[fred_avignon]

en terme objet on peut donc dire que le carré est une instance particulière de la classe rectangle

Une fois votre objet créé en tant qu'instance de la classe Rectangle, vous obtenez un rectangle (une instance de Rectangle) dont les côtés sont de même longueur mais pas une instance d'une classe Carré qui elle, a une seule valeur.

Vous appelez votre instance "carré" mais elle n'a pas les caractéristiques de la classe "Carré".

Sur le fond je pense qu'on est d'accord. C'est juste une question de termes et de point de vue.

[Franck SORIANO]

Drôle de façon de raisonner...

Ben c'est le principe même de l'abstraction... et de la programmation objet.

Une seule valeur permet de définir un carré.

Non, il en faut beaucoup plus. Un carré est un ensemble de points. Pour définir complètement un carré, tu doit connaître l'ensemble de ses points.
Lorsque tu connais une dimension du carré, tu utilises cette dimension ET les propriétés hérités des figures dont il descend pour connaitre les autres points :
- Un carré est un quadrillatère : une figure avec 4 côtés. Donc déjà il te faut 4 longueur pour le définir.
- Un carré est un losange, donc la longueur de chaque côté est égale : Lorsque tu connais une des longueurs, tu en déduis les 3 autres. Cependant, elles existent bel et bien !
- Un carré est un losange qui possède un angle droit : La encore, un carré possède 4 angles. Mais la somme des angles doit faire 360°. Le losange est symétrique... donc il suffit d'un angle pour connaitre les 3 autres...

Comme tu peux le voir, il faut beaucoup plus qu'une longueur pour définir un carré. On utilise un tas de règles pour déterminer les autres éléments. Cependant ils existent qu'en même bel et bien.

L'erreur que tu commets,c'est de bâtir ton modèle d'après l'usage que tu vas faire des objets : Un carré avec une seule dimension. Puis un coefficient de dillatation du carré pour le déformer en rectangle...
Ca signifie que tu fais une modélisation basée sur le fonctionnel. Le modèle repose sur le fonctionnel.
Le problème c'est que fonctionnel sera ammené à évoluer. Si les bases du modèle changent, c'est toute la modélisation qui risque de s'effondrer.

Lorsqu'on fait de la programmation objet, on modélise d'après la nature intrinsèque des objets. Parce que peut importe comment les fonctionnalités évolueront, les règles de la physique, de la chimie et des mathématiques ne vont pas changer. L'objet physique sera toujours le même.
Autrement dit, un objet définit aujourd'hui restera valable demain.
Ce sont les inter-actions de différents objets qui déterminent les fonctionnalités. Si ces dernières doivent changer, il suffit de modifier les objets en présence : Remplacer un objet par un autre qui posède d'autre propriétés, assembler les objets différemment...

C'est alors que le LSP prend toute son importance... pour que le modèle continue à fonctionner quels que soient les substitutions effectuées.

Le défaut qui est mis en évidence par cette discussion, c'est de croire que l'héritage sert à factoriser le code. Ca peut être un effet secondaire bénéfique, mais l'héritage ne sert pas à ça et il ne faut pas l'utiliser pour ça.

[pseudocode]

Une fois votre objet créé en tant qu'instance de la classe Rectangle, vous obtenez un rectangle (une instance de Rectangle) dont les côtés sont de même longueur mais pas une instance d'une classe Carré qui elle, a une seule valeur.

Vous appelez votre instance "carré" mais elle n'a pas les caractéristiques de la classe "Carré".

Sur le fond je pense qu'on est d'accord. C'est juste une question de termes et de point de vue.

Il n'y a pas de "classe" Carré dans mon exemple. Seulement une classe rectangle. Dans cette modélisation, le carré est une instance particulière.

Si on veut modéliser la classe Carré, on doit le faire mais sans utiliser l'héritage. En effet une instance de Rectangle n'a pas le meme comportement qu'une instance de Carré (et réciproquement). On peut a la rigueur utiliser une composition.