Discussion :

[hegros]

En se creusant la tête il y a peut-être moyen de pondre des hiérarchies, mais vous me paressez passer à côté de l'"exercice" : on ne demande pas de trouver la bonne hiérarchie qui va bien entre carrés et rectangles, mais de comprendre ce que substituable veut dire.

Dans ma tête lorsqu'on trouve la juste hiérarchie, celle qui concrétement va bien pour le monde que l'on modèlise, on ne devrait pas se planter. En tout cas on ne devrait pas trouver choquant que dans un monde (farfelu pourquoi pas ) on trouve qu'un carré hérite d'un rectangle.

Ce que je comprends aussi c'est qu'un carré et un cas particulier d'un rectangle (largeur=longueur) ce n'est donc pas forcément idiot de faire hériter l'un de l'autre. Si on veut satisfaire cette particularité dans Carre on pourrait toujours lui faire implémenter une interface cependant ce n'est pas du grand art non plus que de le faire...

[Luc Hermitte]

OK. Vous n'êtes pas réceptifs. Oubliez ces fichus Carrés et Rectangles.

Deux questions. Au choix :
- qu'avez-vous compris du LSP ? (vu seul ça est important, c'est d'ailleurs le coeur de l'opposition carré <-> rectangle)
- ou comment arriverez-vous à me justifier qu'une ListeTriée soit substituable à une Liste (héritage public en C++, héritage tout court en Java, ...)

[hegros]

- qu'avez-vous compris du LSP ? (vu seul ça est important, c'est d'ailleurs le coeur de l'opposition carré <-> rectangle)

en cours de lecture...je viens de voir un exemple qui utilise les exceptions dans le constructeur de carre si hauteur différent largeur

un autre exemple

- ou comment arriverez-vous à me justifier qu'une ListeTriée soit substituable à une Liste (héritage public en C++, héritage tout court en Java, ...)

ok ce n'est pas forcément trés joli en héritage parce que l'opération de tri peut se faire dans une Liste (suffit d'y ajouter la méthode sort)

voilà du code java plutôt simpliste mais bon quand ca devient trop compliqué aprés mieux vaut un peu de code ou un modèle uml cela peut aider...

Code :

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

1
2
3
4
5
class Liste
{
   //---Constructeurs
   //---Les opérations 
}

Code :

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

1
2
3
4
class ListeTriee extends Liste 
{
   //---héritage des opérations de Liste
}

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class Test 
{
   public static void main(String  []argv]
   {

      // a la place de new Liste(), plutôt simpliste comme exemple
      //enfin c'est plus ou moins la représentation que je peux me
      //me faire de la substitution, si tu as un exemple en c++,java
      //you're welcome !
      Liste liste = new ListeTriee (); 
      liste.affiche();
      
   }
}

[Luc Hermitte]

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
void f(Liste [inout] l) {
    l.vider();
    l.ajouteALaFin(2);
    l.ajouteALaFin(1);
    assert(l[l.size()-2] == 2); // post conditions de f
    assert(l[l.size()-1] == 1);
}
...
ListeTriee lt;
f(lt);
foreach ( 0 <= i < j < lt.size() )  // invariant des listes triées
    assert(lt(i) <= lt(j);

Tu peux le tourner dans tous les sens, tu ne peux pas toujours substituer une liste triée à un liste. Une liste triée ne doit donc en aucun cas dériver d'une liste.
Ou alors, il ne faut pas se vanter de coder dans un langage fortement typé quand on commet ce genre d'horreurs.

[Woodruf]

Lors de mon cours de java, on nous a mis en garde à propos de cet exemple, en nous faisans remarquer que justement c'était rectangle qui héritait de carré, même si ce n'est pas la vue des mathématiques. Et du coup, les problèmes sont beaucoup moins nombreux... il ne reste plus qu'un problème principal : si l'on définit un rectangle ayant deux côtés de même longueur...

[souviron34]

ayant lu ce débat, et ayant pas mal travaillé en géométrie (mais pas en langage objet, mais en orienté objet), je vous suggère une classification autre :

classe de base : polygone

[roudoudouduo]

Il est sûr et certain que rectangle n'hérite pas de carré, car la modélisation orientée objet se doit de montrer une réalité et non pas de modéliser une conception pour arranger la réalisation (ce qui est une approche horrible).

On ne peut pas dire que le rectangle le losange ou le carré doivent posséder des méthodes supplémentaires à celle que l'on peut définir dans quadrilatère, ce qui ne rend pas obligatoire l'utilisation de l'héritage.

Je verrais une approche par état :
- une classe QuadrilatereType qui définit les différents types de quadrilatère (carré, rectangle, parrallélogramme) avec une méthode isQuadrialtereOfThisType(Quadrilatere q) ;
- une classe quadrilatère immuable qui a une methode QuadrilatereType getTypeOfQuadrilatere().

Le fait de spécialiser n'oblige pas à utiliser l'héritage, il existe toujours bcp de moyens pour modéliser un concept (et le plus instinctif n'est pas forcément le bon).

[chaplin]

Quand je lis cet article:

http://www.mathsgeo.net/rep/qpar.html

Dont j'ai pris quelques définitions:

Le terme de parallélogramme désigne en fait une grande famille de quadrilatères aux nombreuses propriétés.
Le carré: est un quadrilatère qui est à la fois rectangle et losange.
Le losange: est un quadrilatère qui a ses quatre côtés de même longueur.
Le rectangle: est un quadrilatère qui possède 4 angles droits.

Je serais plus tenté de parlé d'état d'une classe parallèlogramme, {Losange,Rectangle} avec Carré=Rectangle+Losange, héritant de quadrilatère.

J'écris ceci par rapport à un post qui dit que rectangle hérite de carré.

[pseudocode]

"Est-ce que le carré dérive de rectangle, ou alors est-ce le rectangle qui dérive du carré ?"

Ah.... j'adore ces questions pièges. Car le piège n'est pas là où on le pense !! La réponse est : "ni l'un, ni l'autre !!"

une bonne réponse possible est "un Carré est une instance de la classe Rectangle"

Code java :

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

Rectangle carré = new Rectangle(length,length);

Et dans ce cas, on peut réellement dire qu'un carré est un rectangle:

Code java :

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

assert(carré instanceof Rectangle);

De cette définition, on peut créer une classe Carré qui utilisera un rectangle comme attribut privé.

Code java :

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

1
2
3
4
5
6
7
 
class Carré {
    private Rectangle instance;
    public Carré(int length) {
        this.instance = new Rectangle(length,length);
    }
}

[Luc Hermitte]

C'est bien plus qu'une question, c'est un des (2?) exemples scolaires servant à expliquer le LSP.
Héritez tant que vous le voulez l'un de l'autre ou le contraire, le design sera toujours bancal

[Alp]

Tout à fait d'accord avec Luc et pseudocode.

Il ne s'agit pas de modéliser OO à tout prix, même si on n'utilise pas le bon design.

Un carré peu (doit ?) utiliser un rectangle pour son implémentation, mais modéliser l'un dérivant de l'autre c'est une faute au sens du LSP, qui est au coeur même de l'héritage et du polymorphisme.
Et ça me semble cher payé d'hériter sans vouloir de la substituabilité juste pour ne pas avoir à réécrire du code... Car on peut faire autrement pour ce cas là.

[pseudocode]

Et ça me semble cher payé d'hériter sans vouloir de la substituabilité juste pour ne pas avoir à réécrire du code... Car on peut faire autrement pour ce cas là.

La factorisation du code peut se faire par la délégation, ce qui soit dit en passant est beaucoup plus propre, et permet une bien meilleure réutilisation du code.

Je peux compter sur les doigts des 2 mains les fois où j'ai vraiment pu utiliser l'héritage sur des entités "métier". Et sur les doigts d'une seule les fois où ça n'a pas été remplacé plus tard par une interface.

D'une manière générale, quand on est obligé de redéfinir (override) une méthode dans une classe héritée, c'est que l'héritage ne devait pas être la bonne solution.

[Alp]

La factorisation du code peut se faire par la délégation, ce qui soit dit en passant est beaucoup plus propre, et permet une bien meilleure réutilisation du code.

Je peux compter sur les doigts des 2 mains les fois où j'ai vraiment pu utiliser l'héritage sur des entités "métier". Et sur les doigts d'une seule les fois où ça n'a pas été remplacé plus tard par une interface.

D'une manière générale, quand on est obligé de redéfinir (override) une méthode dans une classe héritée, c'est que l'héritage ne devait pas être la bonne solution.

Tout à fait.

Une relation d'héritage est beaucoup trop forte, et devient très gênante et peu pratique quand elle n'était pas justifiée.
La composition est (bien plus souvent que la plupart des programmeurs OO ne le pensent) une meilleure solution.

Herb Sutter en a pas mal parlé à l'époque sur le GOTW (http://www.gotw.ca/gotw/).

[Luc Hermitte]

Dans mes classes métiers, j'ai pas mal d'héritage, et pas du tout au sens interface creuse à la java. J'ai des commonalities [1] qui sont vraiment propres à mes classes métiers, et les variations points[1] sont définis par héritage (public/LSPien) + redéfinitions de fonctions d'opérations. Certes j'aurais pu vider la classe mère de tout comportement, mais cela serait exposer des interfaces avec toutes leurs fonctions en public et rompre des encapsulations.
Mon langage de développement me permet de faire des classes abstraites riches, pourquoi me priver?


[1] Pour reprendre le vocabulaire de J.O. Coplien

[pseudocode]

Mon langage de développement me permet de faire des classes abstraites riches, pourquoi me priver?

Certes, l'héritage peut a la fois respecter le LSP et également permettre de factoriser du code. Ma remarque était plus un "retour d'expérience" sur les projets avec un SDLC du genre Extrem Programming. Voila comment ça se passe chez moi:

• Généralement, on commence par créer une classe "métier" concrète.
  
• Puis pour "étendre" le comportement on créé une copie de cette classe, en modifiant/ajoutant le code spécifique.
  
• Puis, dans une phase de refactor, on fusionne le code en créant une classe abstraite et 2 classe dérivées. Plus on spécialise les classes dérivées, moins on a de code "commun" dans la classe abstraite.
  
• A la fin, on fini par remplacer la classe abstraite par une interface et faire 2 implémentations. Le code "commun" restant peut être extrait dans une classe spécifique (non métier) qui sera utilisée par les 2 implémentations.

A noter que le nombre de classe/interface augmente de plus en plus. Au départ on avait 2 classes "metier" concretes, et a la fin on se retrouve avec 1 interface + 2 classes "metier" + 1 classe "non métier". Cependant le design est beaucoup plus propre (au sens "simple" et "séparé") et donc le code est plus facile a maintenir.

[Luc Hermitte]

Il y a un truc qui me perturbe dans tes appellations, en ce qui me concerne, les commonalities font aussi parti du métier. Ma classe abstraite de base expose des opérations publiques qui relève du Template Metod/Pattern NVI (Non Virtual Interface)

[chaplin]

J'ai réagi sur cette discussion par rapport à ce lien alors que je cherchais des exemples de design patterns:

Inheritance is evil, and must be destroyed

[pseudocode]

Il y a un truc qui me perturbe dans tes appellations, en ce qui me concerne, les commonalities font aussi parti du métier. Ma classe abstraite de base expose des opérations publiques qui relève du Template Metod/Pattern NVI (Non Virtual Interface)

hum... c'est vrai que les commonalities font partie du métier. Mais comme c'est une partie commune que l'on a réussi à extraire de 2 entités métier, cela sous-entend (parfois) que les commonalities ont une autonomie métier.

Bon, ca devient un peu abstrait. Prenons donc un exemple (assez stupide) avec nos amis Rectangle/carrés. Au début on a une classe métier "Carré":

Code java :

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

1
2
3
4
5
6
7
8
9
10
11
 
class Carre {
	private int side;
	public int computeArea() {return side*side;}
	public int computePerimeter() {return 4*side;}
	public int computeFormFactor() {
		int perimeter = computePerimeter();
		if (perimeter==0) return 0;
		return computeArea()/perimeter;
	}
}

Ensuite, on décide de créer la classe metier "Rectangle" en dupliquant le code:

Code java :

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

1
2
3
4
5
6
7
8
9
10
11
 
class Rectangle {
	private int width,height;
	public int computeArea() {return width*height;}
	public int computePerimeter() {return 2*(width+height);}
	public int computeFormFactor() {
		int perimeter = computePerimeter();
		if (perimeter==0) return 0;
		return computeArea()/perimeter;
	}
}

Vient alors un cycle de refactor dans lequel on décide de factoriser le code commun, ici computeFormFactor():

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
19
20
 
abstract class Surface {
	public abstract int computeArea();
	public abstract int computePerimeter();
	public int computeFormFactor() {
		int perimeter = computePerimeter();
		if (perimeter==0) return 0;
		return computeArea()/perimeter;
	}
}
class Carre1 extends Surface {
	private int side;
	public int computeArea() {return side*side;}
	public int computePerimeter() {return 4*side;}
}
class Rectangle1 extends Surface {
	private int width,height;
	public int computeArea() {return width*height;}
	public int computePerimeter() {return 2*(width+height);}
}

C'est dans ces cas là qu'on peut donner une "autonomie" métier au calcul du facteur de forme, en créant une classe dédiée. De ce fait, la classe abstraite peut être remplacée par une simple interface:

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
19
20
21
22
23
24
 
interface ISurface {
	int computeArea();
	int computePerimeter();
	int computeFormFactor();
}
class Carre2 implements ISurface {
	private int side;
	public int computeArea() {return side*side;}
	public int computePerimeter() {return 4*side;}
	public int computeFormFactor() {return FormFactor.compute(computeArea(),computePerimeter());}
}
class Rectangle2 implements ISurface {
	private int width,height;
	public int computeArea() {return width*height;}
	public int computePerimeter() {return 2*(width+height);}
	public int computeFormFactor() {return FormFactor.compute(computeArea(),computePerimeter());}
}
static class FormFactor {
	static int compute(int area,int perimiter) {
		if (perimiter==0) return 0;
		return area/perimiter;
	}
}

Bon, cet exemple n'est pas particulierement pertinent () mais ca montre l'évolution que je rencontre habituellement dans des projets Extrem-Programming.

[chaplin]

Pourtant si je regarde à nouveau l'article mis en lien, il y est dit:

Les nombres 1, 2 et 3 sur fond bleu indique un "niveau d'héritage".
Par exemple:
Le niveau 3 est le niveau qu'il faut atteindre pour obtenir un carré (c'est le quadrilatère qui hérite de toutes les propriétés).
Le niveau 2 est le niveau à atteindre pour obtenir un losange ou un rectangle.
Le niveau 1 est celui qu'il faut atteindre pour obtenir un parallélogramme.

Vu l'ennoncé, il faut croire que l'héritage multiple est la solution (quand c'est possible, en l'occurence en C++),
sachant que l'aire d'un parallèlogramme est soit DC x h1 soit AD x h2 si on considère les quatres sommets ABCD
du parallèlogramme et non LXH pour le rectangle et LXL ou hXh pour le carré.

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

Je peux me tromper

Cela dit j'ai encore appris, c'était une discussion interessante.

[Luc Hermitte]

Cela ne change rien. En fait si, c'est pire car il y a cette fois de nouveaux invariants relatifs à l'angle des côtés.