“doc” (Col. : Science Sup 17x24) — 2007/7/19 — 18:18 — page 225 — #235
i
i
i
i
i
i
i
i
5.2 L’état et la construction de systèmes
225
pour les connaissances fixées à sa création. Pour être précis, comme une procédure
n’a pas d’état, toutes ses connaissances sont dans ses arguments. La programmation
déclarative est comme un organisme qui maintient toutes ses connaissances à l’extérieur, dans l’environnement. Malgré sa revendication du contraire (voir l’épigraphe
à la tête du chapitre), c’était exactement la situation de Louis XIV : l’état n’était pas
dans sa personne mais autour de lui, dans la France du XVII
e siècle. On en conclut
que le principe d’abstraction n’est pas bien soutenu par la programmation déclarative,
car on ne peut pas mettre de nouvelles connaissances dans un composant.
Le chapitre 4 a partiellement résolu ce problème en ajoutant la concurrence. Les
objets à flots peuvent accumuler des connaissances dans leurs arguments internes.
Mais l’usage de ces connaissances est limité parce qu’il n’y a pas de modularité. Dans
ce chapitre, nous avons de l’état sans la concurrence, ce qui est avantageux pour la
modularité.
5.2.1 Les propriétés du système
Quelles propriétés un système devrait-il avoir pour soutenir au mieux le principe
d’abstraction ? En voici trois :
– Encapsulation. Il devrait être possible de cacher l’intérieur d’une partie du système du reste.
– Compositionnalité. Il devrait être possible de combiner des parties de système
pour faire une nouvelle partie.
– Instanciation/invocation. Il devrait être possible de créer de nombreuses instances
d’une partie à partir d’une définition. Ces instances se « connectent » dans leur
environnement (le reste du système dans lequel ils vivront) quand elles sont
créées.
Ces propriétés nécessitent un soutien du langage de programmation, par exemple la
portée lexicale soutient l’encapsulation et la programmation d’ordre supérieur soutient
l’instanciation. Ces propriétés ne nécessitent pas d’état ; elles peuvent aussi être utilisées dans la programmation déclarative. Par exemple, l’encapsulation est orthogonale
à l’état. D’un côté, il est possible d’utiliser l’encapsulation dans les programmes déclaratifs sans état ; nous l’avons déjà fait de nombreuses fois, par exemple dans les objets
à flots. De l’autre, il est possible d’utiliser l’état sans encapsulation, si on définit l’état
globalement pour que tous les composants puissent y accéder.
Les invariants
L’encapsulation et l’état explicite sont plus utiles quand ils sont utilisés ensemble.
Ajouter l’état à la programmation déclarative complique le raisonnement sur un programme, parce que son comportement dépend de l’état. Par exemple, une procédure
© Dunod – La photocopie non autorisée est un délit
i
i
i
i
i
i
i
i
5.2 L’état et la construction de systèmes
225
pour les connaissances fixées à sa création. Pour être précis, comme une procédure
n’a pas d’état, toutes ses connaissances sont dans ses arguments. La programmation
déclarative est comme un organisme qui maintient toutes ses connaissances à l’extérieur, dans l’environnement. Malgré sa revendication du contraire (voir l’épigraphe
à la tête du chapitre), c’était exactement la situation de Louis XIV : l’état n’était pas
dans sa personne mais autour de lui, dans la France du XVII
e siècle. On en conclut
que le principe d’abstraction n’est pas bien soutenu par la programmation déclarative,
car on ne peut pas mettre de nouvelles connaissances dans un composant.
Le chapitre 4 a partiellement résolu ce problème en ajoutant la concurrence. Les
objets à flots peuvent accumuler des connaissances dans leurs arguments internes.
Mais l’usage de ces connaissances est limité parce qu’il n’y a pas de modularité. Dans
ce chapitre, nous avons de l’état sans la concurrence, ce qui est avantageux pour la
modularité.
5.2.1 Les propriétés du système
Quelles propriétés un système devrait-il avoir pour soutenir au mieux le principe
d’abstraction ? En voici trois :
– Encapsulation. Il devrait être possible de cacher l’intérieur d’une partie du système du reste.
– Compositionnalité. Il devrait être possible de combiner des parties de système
pour faire une nouvelle partie.
– Instanciation/invocation. Il devrait être possible de créer de nombreuses instances
d’une partie à partir d’une définition. Ces instances se « connectent » dans leur
environnement (le reste du système dans lequel ils vivront) quand elles sont
créées.
Ces propriétés nécessitent un soutien du langage de programmation, par exemple la
portée lexicale soutient l’encapsulation et la programmation d’ordre supérieur soutient
l’instanciation. Ces propriétés ne nécessitent pas d’état ; elles peuvent aussi être utilisées dans la programmation déclarative. Par exemple, l’encapsulation est orthogonale
à l’état. D’un côté, il est possible d’utiliser l’encapsulation dans les programmes déclaratifs sans état ; nous l’avons déjà fait de nombreuses fois, par exemple dans les objets
à flots. De l’autre, il est possible d’utiliser l’état sans encapsulation, si on définit l’état
globalement pour que tous les composants puissent y accéder.
Les invariants
L’encapsulation et l’état explicite sont plus utiles quand ils sont utilisés ensemble.
Ajouter l’état à la programmation déclarative complique le raisonnement sur un programme, parce que son comportement dépend de l’état. Par exemple, une procédure
© Dunod – La photocopie non autorisée est un délit