“doc” (Col. : Science Sup 17x24) — 2007/7/19 — 18:18 — page 248 — #258
i
i
i
i
i
i
i
i
248
5
• La programmation avec état explicite
et nous pourrions faire une addition avec une instruction machine. Cela explique
pourquoi des langages orientés objet populaires comme Java utilisent le style
ADT pour les opérations primitives sur des types de base comme des entiers.
– Dans le style objet, le polymorphisme ne coûte « rien ». Supposons que nous
définissions un deuxième type de collection (avec un objet D) ayant la même
interface que le premier. Alors les deux types de collections peuvent interopérer
même si leurs implémentations sont indépendantes. Bref, {C union(D)} est
correct sans écrire une seule ligne de code en plus !
5
– Le style objet n’est pas limité aux objets séquentiels. En particulier, les objets
à flots (voir chapitre 4) sont aussi des objets comme nous les avons définis. Ils
soutiennent le polymorphisme tout comme les objets séquentiels.
– Le style ADT pourra soutenir le polymorphisme si le langage a des modules de
première classe. Supposons que nous définissions un deuxième type de collection
comme un module Collection2. L’implémentation d’union doit alors s’assurer que C2 utilise toujours une opération de Collection2. Nous pouvons le
faire en ajoutant Collection2 comme un argument à l’opération union, ce
qui donne l’appel {Union C1 Collection2 C2}. La définition est :
proc {Union C1 Collection2 C2}
{DoUntil fun {$} {Collection2.isEmpty C2} end
proc {$}
{Collection.put C1 {Collection2.get C2}} end}
end
Collection=collection(... union:Union)
Cette technique est souvent utilisée dans les langages avec des modules de première classe, comme Erlang.
– Si nous utilisons le style ADT sans modules de première classe, il faudra écrire
du code supplémentaire pour faire interopérer les types. Nous devons écrire une
opération union qui connaît les deux représentations internes. Si nous avons
trois ou plus de trois types de collection, l’implémentation deviendra encore plus
embrouillée : il faudra implémenter toutes les combinaisons de deux types.
Les langages orientés objet utilisent le style objet par défaut, ce qui les rend polymorphes par défaut. C’est un des grands avantages de la programmation orientée objet.
Nous l’explorerons davantage dans le chapitre 6.
5. Cela peut paraître miraculeux. L’appel fonctionne car l’implémentation en C de union n’appelle
que l’interface externe de D. Réfléchissez-y !
i
i
i
i
i
i
i
i
248
5
• La programmation avec état explicite
et nous pourrions faire une addition avec une instruction machine. Cela explique
pourquoi des langages orientés objet populaires comme Java utilisent le style
ADT pour les opérations primitives sur des types de base comme des entiers.
– Dans le style objet, le polymorphisme ne coûte « rien ». Supposons que nous
définissions un deuxième type de collection (avec un objet D) ayant la même
interface que le premier. Alors les deux types de collections peuvent interopérer
même si leurs implémentations sont indépendantes. Bref, {C union(D)} est
correct sans écrire une seule ligne de code en plus !
5
– Le style objet n’est pas limité aux objets séquentiels. En particulier, les objets
à flots (voir chapitre 4) sont aussi des objets comme nous les avons définis. Ils
soutiennent le polymorphisme tout comme les objets séquentiels.
– Le style ADT pourra soutenir le polymorphisme si le langage a des modules de
première classe. Supposons que nous définissions un deuxième type de collection
comme un module Collection2. L’implémentation d’union doit alors s’assurer que C2 utilise toujours une opération de Collection2. Nous pouvons le
faire en ajoutant Collection2 comme un argument à l’opération union, ce
qui donne l’appel {Union C1 Collection2 C2}. La définition est :
proc {Union C1 Collection2 C2}
{DoUntil fun {$} {Collection2.isEmpty C2} end
proc {$}
{Collection.put C1 {Collection2.get C2}} end}
end
Collection=collection(... union:Union)
Cette technique est souvent utilisée dans les langages avec des modules de première classe, comme Erlang.
– Si nous utilisons le style ADT sans modules de première classe, il faudra écrire
du code supplémentaire pour faire interopérer les types. Nous devons écrire une
opération union qui connaît les deux représentations internes. Si nous avons
trois ou plus de trois types de collection, l’implémentation deviendra encore plus
embrouillée : il faudra implémenter toutes les combinaisons de deux types.
Les langages orientés objet utilisent le style objet par défaut, ce qui les rend polymorphes par défaut. C’est un des grands avantages de la programmation orientée objet.
Nous l’explorerons davantage dans le chapitre 6.
5. Cela peut paraître miraculeux. L’appel fonctionne car l’implémentation en C de union n’appelle
que l’interface externe de D. Réfléchissez-y !