“doc” (Col. : Science Sup 17x24) — 2007/7/19 — 18:18 — page 293 — #303
i
i
i
i
i
i
i
i
6.4 La programmation avec l’héritage
293
Si A est un objet AccountWithFee, cela implique B+S-@fee=B2. Si @fee = 0
le contrat n’est plus satisfait. Cela cassera tout programme qui dépend du comportement des objets Account. Quand cette erreur arrive dans un grand programme, son
origine n’est généralement pas évidente parce qu’elle est cachée à l’intérieur d’une
méthode. Elle apparaîtra comme un léger déséquilibre dans les comptes, longtemps
après que l’on ait oublié la classe AccountWithFee. Le débogage de ce genre de
« petits » problèmes est extraordinairement difficile et souvent interminable.
À partir de maintenant nous allons nous concentrer sur la vue de type. Quoi qu’il
en soit, la vue de structure est parfois utile. Son utilisation principale est de changer
le comportement du système à objets lui-même. Dans ce but, elle doit être utilisée
uniquement par des experts qui comprennent clairement les ramifications de ce qu’ils
font. Pour plus d’informations, nous recommandons [65] pour une comparaison plus
approfondie de la vue de type et de la vue de structure.
La conception par contrat
Nous disons qu’un programme est correct ou exact s’il s’exécute selon sa spécification. Une manière de prouver l’exactitude d’un programme est un raisonnement basé
sur une sémantique formelle. Par exemple, avec un programme à état nous pouvons
raisonner avec la sémantique axiomatique (voir un des nombreux livres sur la sémantique axiomatique). Nous pouvons aussi raisonner avec des règles algébriques, comme
dans l’exemple Account. En se basant sur ces deux techniques, Bertrand Meyer a
développé une méthode pour la conception de programmes corrects qui s’appelle la
conception par contrat (« design by contract ») et il l’a implémentée dans le langage
Eiffel [65].
L’idée principale de la conception par contrat est qu’une abstraction de données
implique un contrat entre le concepteur de l’abstraction et ses utilisateurs. Les utilisateurs doivent garantir que l’abstraction est appelée correctement ; en échange
l’abstraction se comportera correctement. Il y a une analogie avec les contrats dans la
société humaine. Le contrat peut être formulé avec des règles algébriques, comme nous
l’avons fait dans l’exemple Account, ou avec les préconditions et les postconditions.
L’utilisateur s’assure que les préconditions sont toujours vraies avant d’appeler une
opération. L’implémentation de l’abstraction de données s’assure alors que les postconditions seront toujours vraies quand l’opération se terminera. Il y a une répartition
des responsabilités : l’utilisateur est responsable pour les préconditions et l’abstraction
de données est responsable pour les postconditions.
L’abstraction de données vérifie que l’utilisateur respecte le contrat. C’est particulièrement facile si on utilise les préconditions et les postconditions. Les préconditions
sont vérifiées à la frontière entre l’utilisateur et l’abstraction. Une fois à l’intérieur
de l’abstraction, nous pouvons supposer que les préconditions sont satisfaites. Aucun
test n’est fait à l’intérieur de l’abstraction, ce qui simplifie son implémentation. C’est
© 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
293
Si A est un objet AccountWithFee, cela implique B+S-@fee=B2. Si @fee = 0
le contrat n’est plus satisfait. Cela cassera tout programme qui dépend du comportement des objets Account. Quand cette erreur arrive dans un grand programme, son
origine n’est généralement pas évidente parce qu’elle est cachée à l’intérieur d’une
méthode. Elle apparaîtra comme un léger déséquilibre dans les comptes, longtemps
après que l’on ait oublié la classe AccountWithFee. Le débogage de ce genre de
« petits » problèmes est extraordinairement difficile et souvent interminable.
À partir de maintenant nous allons nous concentrer sur la vue de type. Quoi qu’il
en soit, la vue de structure est parfois utile. Son utilisation principale est de changer
le comportement du système à objets lui-même. Dans ce but, elle doit être utilisée
uniquement par des experts qui comprennent clairement les ramifications de ce qu’ils
font. Pour plus d’informations, nous recommandons [65] pour une comparaison plus
approfondie de la vue de type et de la vue de structure.
La conception par contrat
Nous disons qu’un programme est correct ou exact s’il s’exécute selon sa spécification. Une manière de prouver l’exactitude d’un programme est un raisonnement basé
sur une sémantique formelle. Par exemple, avec un programme à état nous pouvons
raisonner avec la sémantique axiomatique (voir un des nombreux livres sur la sémantique axiomatique). Nous pouvons aussi raisonner avec des règles algébriques, comme
dans l’exemple Account. En se basant sur ces deux techniques, Bertrand Meyer a
développé une méthode pour la conception de programmes corrects qui s’appelle la
conception par contrat (« design by contract ») et il l’a implémentée dans le langage
Eiffel [65].
L’idée principale de la conception par contrat est qu’une abstraction de données
implique un contrat entre le concepteur de l’abstraction et ses utilisateurs. Les utilisateurs doivent garantir que l’abstraction est appelée correctement ; en échange
l’abstraction se comportera correctement. Il y a une analogie avec les contrats dans la
société humaine. Le contrat peut être formulé avec des règles algébriques, comme nous
l’avons fait dans l’exemple Account, ou avec les préconditions et les postconditions.
L’utilisateur s’assure que les préconditions sont toujours vraies avant d’appeler une
opération. L’implémentation de l’abstraction de données s’assure alors que les postconditions seront toujours vraies quand l’opération se terminera. Il y a une répartition
des responsabilités : l’utilisateur est responsable pour les préconditions et l’abstraction
de données est responsable pour les postconditions.
L’abstraction de données vérifie que l’utilisateur respecte le contrat. C’est particulièrement facile si on utilise les préconditions et les postconditions. Les préconditions
sont vérifiées à la frontière entre l’utilisateur et l’abstraction. Une fois à l’intérieur
de l’abstraction, nous pouvons supposer que les préconditions sont satisfaites. Aucun
test n’est fait à l’intérieur de l’abstraction, ce qui simplifie son implémentation. C’est
© Dunod – La photocopie non autorisée est un délit