Discussion :

[chaplin]

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

Parler de carré ou de rectangle, revient à parler de formes géométriques particulières. Dans de telles circonstances j'utiliserais une fabrique de classe.
Néanmoins, il faudrait savoir de quel énoncé on part, et je suis d'accord qu'en fonction de ce qui y est décrit l'héritage fonctionne ou non.
Dois je comprendre que si on modifirait quelque peu l'énoncé, l'héritage est une forme de modélisation qui montre rapidement ses limites, je n'ai pas dit le contraire. J'ai voulu démontrer qu'en prenant un type d'énoncé LSP s'applique correctement.

Si on écrirait une méthode pour faire varier les angles au niveau du parallèlogramme, on commet exactement les même erreurs qu'en parlant de longueur et de largeur. A ce moment là carré devient losange, il n'est même pas question de parler de rectangle. Je partage l'avis de souviron34, que certains modèles de pensées informatiques nous formattent sur nos comportements.

[hegros]

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

Justement cela dépend de ce que tu veux modéliser, je simplifie parce que ce sont des données là élémentaire que tout le monde connaît et qui est tout de suite modélisable car pour l'instant tu parles mais tu ne nous montres pas de modélisation de ce que tu décris.

De plus il est unanimement reconnu que l'héritage a ses limites et que cela a tendance a multiplier considérablement les effets de bords surtout lors d'ajout de nouvelles propriétés ou comportements. Tout cela pour dire que c'est bien beau la théorie des sommets ABCD reste à savoir dans quel contexte pratique tu veux l'appliquer.

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

Tu veux dire une classe rectangle comme cela

class Rectangle
{
int sommetA, sommetB, sommetC, sommetD;
}

Et une class Carre vide qui hérite de Rectangle ?

Code :

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

1
2
3
4
class Carre extends Rectangle
{

}

Je préfére quand même pour Carre la délégation, je trouve cela plus élégant et extensible en dehors de tout contexte.

Code :

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

1
2
3
4
Class Carre
{
   Rectangle r;
}

[pseudocode]

Si on écrirait une méthode pour faire varier les angles au niveau du parallèlogramme, on commet exactement les même erreurs qu'en parlant de longueur et de largeur. A ce moment là carré devient losange, il n'est même pas question de parler de rectangle.

Une limite importante du paradigme objet : l'état d'un objet (=la valeur de ses attributs à un instant donné) ne décide pas de sa classe.

Ce n'est pas parce qu'un objet de la classe Rectangle à ses attributs longueur et largeur egaux qu'il se change en objet de la classe Carré (et inversement).

Cela nous laisse 3 possibilités:

1. Le concept représenté par la classe ne doit pas dépendre de l'état (différencier les modèles d'analyse et de conception).

2. L'état ne doit pas être modifiable (objet immutable).

3. L'état doit rester cohérent avec le concept représenté par la classe (contraintes/exceptions)

Les choix 1 ou 2 garantissent le respect du LSP. Le choix 3 implique des override de méthodes et donc une violation du LSP.

[chaplin]

Une limite importante du paradigme objet : l'état d'un objet (=la valeur de ses attributs à un instant donné) ne décide pas de sa classe.

Ok, je vois où je me suis planté dans mon raisonnement, c'est clairment dit maintenant.. Alors, est il au moins possible que carré, rectangle hérite de parallèlogramme en respectant LSP ?

[Luc Hermitte]

S'ils sont immuables et dénués de tout comportement altérant leur état (i.e. des pures valeurs et non des entités), oui potentiellement, je soupçonne que l'on doit pouvoir tomber sur une modélisation qui mime la classification mathématique usuelle de ces objets.
Ils ne serait alors plus que états immuables et contraintes.

[chaplin]

Justement cela dépend de ce que tu veux modéliser, je simplifie parce que ce sont des données là élémentaire que tout le monde connaît et qui est tout de suite modélisable car pour l'instant tu parles mais tu ne nous montres pas de modélisation de ce que tu décris.

De plus il est unanimement reconnu que l'héritage a ses limites et que cela a tendance a multiplier considérablement les effets de bords surtout lors d'ajout de nouvelles propriétés ou comportements

Exact, je n'ai donné aucun exemple sous forme de code. Le seul élément conducteur de m'a pensée a été LSP qu'a introduit Luc Hermitte. Comme j'ai l'esprit de contradiction, j'ai essayé en vain de trouver un contre exemple (et j'y croyais). Mais à force d'arguments constructifs de toi hegros, Luc Hermitte et Pseudocode, j'ai pris conscience des principes au delà de LSP qui permettent de valider une architecture objet. Depuis des années, je cherchais des méthodes pour valider un modèle objet. Enfin !! j'ai trouvé des principes pour infirmer ou affirmer la "qualité" d'un code objet. Il s'agit non seulement de chercher dans la bonne direction mais aussi accepter qu'on se trompe sur certains préjugés et donc ouvert aux méthodes et les comprendre de bout en bout malgré certaines habitudes de pensées.

[pseudocode]

Alors, est il au moins possible que carré, rectangle hérite de parallèlogramme en respectant LSP ?

Même réponse que précédemment. Tout dépend comment sont modélisées les classes Rectangle/Parallélogramme. J'ai l'impression que tu prends le problème à l'envers. Tu définis la hierarchie entre les classes avant de définir les classes elles-mêmes.

La règle pour définir une classe est que "Les états possibles d'une instance de la classe doivent toujours respecter la définition "metier" de cette classe"

Dans notre cas : "Les états d'une instance de la classe 'Rectangle' doivent toujours être des rectangle au sens géométrique ?". Si tu as défini la classe Rectangle avec 4 attributs 'points', alors il y a des états possibles qui ne sont pas des rectangle => il faut gérer les exceptions.

[chaplin]

Dans notre cas : "Les états d'une instance de la classe 'Rectangle' doivent toujours être des rectangle au sens géométrique ?". Si tu as défini la classe Rectangle avec 4 attributs 'points', alors il y a des états possibles qui ne sont pas des rectangle => il faut gérer les exceptions.

J'ai abandonné l'idée d'utiliser 4 points, si on parle d'un parallèlogramme, 1 point suffit compte tenu des contraintes si on tient compte d'un angle (AB,AD), si on parle d'un carré ou d'un rectangle 1 point suffit avec 1 angle à 90°. Mais, si on dit que l'angle (AB,AD) est variable, je vais tomber dans le même travers

Quoique si je reste sur l'idée des 4 sommets, la contrainte c'est |BA|=|DC| et |BC|=|AD| alors ça marche . C'est la définition d'un parallèlogramme, coté parallèles 2 à 2 et de même longueur. Si je n'introduis pas la notion d'angle, le tour ai joué

[pseudocode]

Si je n'introduis pas la notion d'angle, le tour ai joué

Le but ce n'est pas d'utiliser à tout prix l'héritage dans le modèle de conception, quite à modifier les définitions de classe !

Fais un modèle de conception facile à implémenter/maintenir. L'héritage apparaîtra (s'il existe) au fur et à mesure que la conception évolue. A ce moment là il faudra se poser la question du LSP, mais pas avant.

[hegros]

Disons qu'en abusant de l'héritage on viole aussi un autre principe de conception notamment le couplage qui est trés fort contrairement à la délégation.

[Alp]

Le but ce n'est pas d'utiliser à tout prix l'héritage dans le modèle de conception, quite à modifier les définitions de classe !

Je dirais même "au contraire", dans le sens où dans la majorité des langages, on doit se trimballer des choses en plus lorsque l'on utilise l'héritage (table virtuelle pour les appels de fonctions), et effectivement on a un couplage très fort (i.e la classe fille dépend trèèèès fortement de la classe mère, alors que si dans cette classe tu n'avais qu'un objet de type la classe mère, tu as alors un couplage beaucoup plus faible !

[hegros]

Puisque tu parles de se trimballer des choses une conséquence d'un couplage fort comme l'héritage c'est la violation d'un autre principe de conception la cohésion. Est-ce que tous les attributs de la classe mére vont avoir un "réel" sens pour toutes les classes filles ? Je me demande même si ce n'est pas une fatalité à y regarder dans des frameworks comme java ou dotnet où l'héritage est fraîchement utilisé ce n'est pas toujours clair d'y voir de la cohésion...

[Alp]

Puisque tu parles de se trimballer des choses une conséquence d'un couplage fort comme l'héritage c'est la violation d'un autre principe de conception la cohésion. Est-ce que tous les attributs de la classe mére vont avoir un "réel" sens pour toutes les classes filles ? Je me demande même si ce n'est pas une fatalité à y regarder dans des frameworks comme java ou dotnet où l'héritage est fraîchement utilisé ce n'est pas toujours clair d'y voir de la cohésion...

C'est exactement ma façon de voir les choses.
J'ai beaucoup appris grâce aux bouquins de Herb Sutter, dans lesquels on trouve des partie sur l'héritage.

[chaplin]

Une limite importante du paradigme objet : l'état d'un objet (=la valeur de ses attributs à un instant donné) ne décide pas de sa classe.

Je reviens sur cette proposition, cela veux dire qu'il n'est alors pas question de partler de classe Carré puisqu'il est un cas particulier de rectangle.
En revanche il faudra traiter le cas largeur=longueur pour tenir compte de la forme particulière carré si on veut introduire la notion de carré.

[pseudocode]

Je reviens sur cette proposition, cela veux dire qu'il n'est alors pas question de partler de classe Carré puisqu'il est un cas particulier de rectangle.
En revanche il faudra traiter le cas largeur=longueur pour tenir compte de la forme particulière carré si on veut introduire la notion de carré.

Si la classe Rectangle est définie avec des attributs "longueur" et "largeur" et les getters/setters associés, alors effectivement on ne peut pas utiliser un simple heritage pour définir la classe Carré (sauf à violer le LSP).

C'est pour cela qu'il est préférable d'utiliser la composition, et d'utiliser une instance de Rectangle comme attribut de la classe Carré. Grace à l'encapsulation, seules les methodes de Carré auront accès a cet attribut et pourront donc maintenir la cohérence avec la définition géométrique.

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
16
17
18
 
class Carré {
	private Rectangle rectangle = null;
 
	public Carré(int coté) {
		this.rectangle = new Rectangle(coté,coté);
	}
 
	public int getCoté() {
		return this.rectangle.getLongueur(); /* ou .getLargeur() */
	}
 
	public void setCoté(int coté) {
		// on maintient la cohérence géométrique
		this.rectangle.setLongueur(coté);
		this.rectangle.setLargeur(coté);
	}
}

[chaplin]

Malgré la composition, même si rectangle devient un attribut de carré, sans parler de classe carré, on arrivera aussi au cas carré quand rectangle sera dans le cas largeur=longueur.
Je suis tétu , j'ai cru comprendre que si les attribus d'une classe pouvaient être modifiées (par valeur) de telle sorte qu'on arrive à l'équivalence d'une autre classe(i.e. carré), cette dernière ne pouvait exister.
Ce que je dis est bien équivalent à:

Ce n'est pas parce qu'un objet de la classe Rectangle à ses attributs longueur et largeur egaux qu'il se change en objet de la classe Carré (et inversement).

[pseudocode]

Je suis tétu , j'ai cru comprendre que si les attribus d'une classe pouvaient être modifiées (par valeur) de telle sorte qu'on arrive à l'équivalence d'une autre classe(i.e. carré), cette dernière ne pouvait exister.

"Ne pouvait exister" ? . Je ne vois pas ce que tu veux dire.

Moi j'ai juste dit que la classe d'un objet était fixée une fois pour toute lors de sa création. Meme si par la suite tu modifies l'état d'un objet, sa classe reste la meme.

Donc si Carré et Rectangle sont 2 classes différentes sans lien de parenté (comme dans mon code précédant), une instance de Rectangle ne deviendra jamais une instance de Carré meme si on est dans un état où largeur=longueur.

[chaplin]

Ce qui me gène c'est de parler de classe carré, alors que rectangle englobe le cas particulier carré. Quel est l'interêt de créer une classe alors qu'un autre peut "mimer" son comportement ?

[Luc Hermitte]

Comportement ou état ?

[chaplin]

Dans le cas présent il faudrait parler d'état, sinon le carré rassemble les comportements d'un rectangle et d'un losange.