“doc” (Col. : Science Sup 17x24) — 2007/7/19 — 18:18 — page 244 — #254
i
i
i
i
i
i
i
i
244
5
• La programmation avec état explicite
types (spécialités), aussi longtemps qu’il comprend l’opération gu´ erison. L’objet
patient ne sait pas comment se guérir lui-même ; il ne devrait pas savoir. L’objet
médecin comprend l’opération gu´ erison et fera l’action appropriée.
Toutes les organisations des abstractions de données que nous avons expliquées
auparavant peuvent soutenir le polymorphisme. L’idée de base est simple. Supposez
qu’un programme fonctionne correctement avec une abstraction de données particulière. Alors il a le potentiel de fonctionner avec toute autre abstraction de données ayant
la même interface. Mais le programme est-il toujours correct avec l’autre abstraction
de données ? Il le sera si l’autre abstraction satisfait les mêmes propriétés mathématiques que l’abstraction originale. Le raisonnement qui a montré l’exécution correcte
pour l’abstraction originale devrait être utilisable pour l’autre.
Le style objet présente un avantage sur le style ADT car le polymorphisme y est
particulièrement facile à exprimer avec les objets. Bien que le polymorphisme puisse
être exprimé dans le style ADT, il est plus encombrant car il nécessite des modules de
première classe. Le style ADT a un avantage différent : il donne plus de liberté pour
faire des implémentations efficaces. Donnons un exemple pour clarifier ces différences.
Définissons d’abord un type Collection et implémentons-le dans les styles ADT et
objet. Ajoutons ensuite une opération, union, au type Collection et étendons les deux
implémentations.
5.5.1 Un exemple : le type Collection
Supposons que nous ayons un type Collection avec trois opérations : un put pour
ajouter un élément, un get pour extraire un élément et un isEmpty pour tester si la
collection est vide. Commençons l’exemple en implémentant le type Collection dans
les styles ADT et objet. Implémentons la collection en ADT avec la pile avec état non
agrégée (NewWrapper est définie dans la section 3.5) :
local Wrap Unwrap
{NewWrapper Wrap Unwrap}
fun {NewCollection} {Wrap {Stack.new}} end
proc {Put C X} S={Unwrap C} in {Stack.push S X} end
fun {Get C} S={Unwrap C} in {Stack.pop S} end
fun {IsEmpty C} {Stack.isEmpty {Unwrap C}} end
in
Collection=collection(new:NewCollection put:Put
get:Get isEmpty:IsEmpty)
end
i
i
i
i
i
i
i
i
244
5
• La programmation avec état explicite
types (spécialités), aussi longtemps qu’il comprend l’opération gu´ erison. L’objet
patient ne sait pas comment se guérir lui-même ; il ne devrait pas savoir. L’objet
médecin comprend l’opération gu´ erison et fera l’action appropriée.
Toutes les organisations des abstractions de données que nous avons expliquées
auparavant peuvent soutenir le polymorphisme. L’idée de base est simple. Supposez
qu’un programme fonctionne correctement avec une abstraction de données particulière. Alors il a le potentiel de fonctionner avec toute autre abstraction de données ayant
la même interface. Mais le programme est-il toujours correct avec l’autre abstraction
de données ? Il le sera si l’autre abstraction satisfait les mêmes propriétés mathématiques que l’abstraction originale. Le raisonnement qui a montré l’exécution correcte
pour l’abstraction originale devrait être utilisable pour l’autre.
Le style objet présente un avantage sur le style ADT car le polymorphisme y est
particulièrement facile à exprimer avec les objets. Bien que le polymorphisme puisse
être exprimé dans le style ADT, il est plus encombrant car il nécessite des modules de
première classe. Le style ADT a un avantage différent : il donne plus de liberté pour
faire des implémentations efficaces. Donnons un exemple pour clarifier ces différences.
Définissons d’abord un type Collection et implémentons-le dans les styles ADT et
objet. Ajoutons ensuite une opération, union, au type Collection et étendons les deux
implémentations.
5.5.1 Un exemple : le type Collection
Supposons que nous ayons un type Collection avec trois opérations : un put pour
ajouter un élément, un get pour extraire un élément et un isEmpty pour tester si la
collection est vide. Commençons l’exemple en implémentant le type Collection dans
les styles ADT et objet. Implémentons la collection en ADT avec la pile avec état non
agrégée (NewWrapper est définie dans la section 3.5) :
local Wrap Unwrap
{NewWrapper Wrap Unwrap}
fun {NewCollection} {Wrap {Stack.new}} end
proc {Put C X} S={Unwrap C} in {Stack.push S X} end
fun {Get C} S={Unwrap C} in {Stack.pop S} end
fun {IsEmpty C} {Stack.isEmpty {Unwrap C}} end
in
Collection=collection(new:NewCollection put:Put
get:Get isEmpty:IsEmpty)
end