“doc” (Col. : Science Sup 17x24) — 2007/7/19 — 18:18 — page 291 — #301
i
i
i
i
i
i
i
i
6.4 La programmation avec l’héritage
291
6.4.1 L’utilisation correcte de l’héritage
Il y a deux manières de regarder l’héritage :
– La vue de type. Dans cette vue, les classes sont des types et les sous-classes sont
des sous-types. Par exemple, prenez une classe LabeledWindow qui hérite
d’une classe Window. Toutes les fenêtres étiquetées sont aussi des fenêtres.
La vue de type est cohérente avec le principe selon lequel les classes doivent
modéliser des entités qui existent en dehors du programme. Dans la vue de
type, les classes satisfont la propriété de substitution : chaque opération qui est
valable pour un objet de la classe C l’est aussi pour les objets d’une sous-classe de
C. La plupart des langages orientés objet, comme Java et Smalltalk, sont conçus
pour la vue de type [28, 29].
– La vue de structure. Dans cette vue, l’héritage est simplement un outil pour
structurer les programmes. Cette vue est fortement découragée parce que les
classes ne satisfont plus la propriété de substitution. La vue de structure est une
source inépuisable de bugs et de mauvaises conceptions. Des projets commerciaux majeurs qui resteront anonymes ont échoué pour cette raison.
Certains langages orientés objet, notamment Eiffel, sont conçus pour permettre les
deux vues [65]. Dans la vue de type, chaque classe définit une vraie abstraction de
données. Dans la vue de structure, les classes ne sont parfois que de l’échafaudage,
qui n’existe que pour son rôle de structuration.
Un exemple
Dans la grande majorité des cas, l’héritage doit respecter la vue de type. Faire autrement engendre des bugs subtiles et pernicieux qui peuvent empoisonner tout le système.
Par exemple, prenez la classe Account que nous avons vue auparavant, définie dans
la figure 6.6. Un objet A de cette classe satisfait la règle algébrique suivante :
{A getBalance(b)} {A transfer(s)} {A getBalance(b )}
avec b + s = b
. En mots, avec un solde initial de b et un transfert de s, le solde final
sera b + s. Cette règle algébrique peut être vue comme une spécification de Account,
ou comme un contrat entre Account et le programme qui utilise ses objets. (Dans
une définition pratique de Account, il y aurait d’autres règles. Nous les omettons
pour simplifier l’exemple.) Selon la vue de type, les sous-classes de Account doivent
aussi implémenter ce contrat. Nous étendons maintenant Account deux fois. La
première extension est conservatrice, c’est-à-dire qu’elle respecte la vue de type :
© Dunod – La photocopie non autorisée est un délit
i
i
i
i
i
i
i
i
6.4 La programmation avec l’héritage
291
6.4.1 L’utilisation correcte de l’héritage
Il y a deux manières de regarder l’héritage :
– La vue de type. Dans cette vue, les classes sont des types et les sous-classes sont
des sous-types. Par exemple, prenez une classe LabeledWindow qui hérite
d’une classe Window. Toutes les fenêtres étiquetées sont aussi des fenêtres.
La vue de type est cohérente avec le principe selon lequel les classes doivent
modéliser des entités qui existent en dehors du programme. Dans la vue de
type, les classes satisfont la propriété de substitution : chaque opération qui est
valable pour un objet de la classe C l’est aussi pour les objets d’une sous-classe de
C. La plupart des langages orientés objet, comme Java et Smalltalk, sont conçus
pour la vue de type [28, 29].
– La vue de structure. Dans cette vue, l’héritage est simplement un outil pour
structurer les programmes. Cette vue est fortement découragée parce que les
classes ne satisfont plus la propriété de substitution. La vue de structure est une
source inépuisable de bugs et de mauvaises conceptions. Des projets commerciaux majeurs qui resteront anonymes ont échoué pour cette raison.
Certains langages orientés objet, notamment Eiffel, sont conçus pour permettre les
deux vues [65]. Dans la vue de type, chaque classe définit une vraie abstraction de
données. Dans la vue de structure, les classes ne sont parfois que de l’échafaudage,
qui n’existe que pour son rôle de structuration.
Un exemple
Dans la grande majorité des cas, l’héritage doit respecter la vue de type. Faire autrement engendre des bugs subtiles et pernicieux qui peuvent empoisonner tout le système.
Par exemple, prenez la classe Account que nous avons vue auparavant, définie dans
la figure 6.6. Un objet A de cette classe satisfait la règle algébrique suivante :
{A getBalance(b)} {A transfer(s)} {A getBalance(b )}
avec b + s = b
. En mots, avec un solde initial de b et un transfert de s, le solde final
sera b + s. Cette règle algébrique peut être vue comme une spécification de Account,
ou comme un contrat entre Account et le programme qui utilise ses objets. (Dans
une définition pratique de Account, il y aurait d’autres règles. Nous les omettons
pour simplifier l’exemple.) Selon la vue de type, les sous-classes de Account doivent
aussi implémenter ce contrat. Nous étendons maintenant Account deux fois. La
première extension est conservatrice, c’est-à-dire qu’elle respecte la vue de type :
© Dunod – La photocopie non autorisée est un délit