Classes et objets
CHAPITRE 9
186
{ retourne abs
}
entier méthode valeurOrd
{ retourne ord
}
On peut alors légitimement se poser la question de l’intérêt d’encapsuler les attributs si on
peut les connaître ou les modifier à volonté à l’aide de méthodes d’accès ou d’altération.
Pourquoi ne pas en autoriser l’accès direct ? En fait, la réponse réside dans la distinction
entre ce que l’on nomme l’interface d’une classe et son implémentation et dont nous allons
parler maintenant.
3.2 Notions d’interface, de contrat et d’implémentation
L’interface d’une classe corresond aux informations dont on doit pouvoir disposer pour pouvoir l’utiliser. Il s’agit :
• du nom de la classe ;
• de la signature (nom de la fonction et type des paramètres) et du type du résultat éventuel
de chacune de ses méthodes.
Dans le cas de notre classe Point, ces informations pourraient se résumer ainsi :
classe Point
{ méthode initialise (entier, entier)
méthode déplace (entier, entier)
méthode affiche
}
Le contrat d’une classe correspond à son interface et à la définition du rôle de ses méthodes.
Enfin, l’implémentation d’une classe correspond à l’ensemble des instructions de la classe,
écrites en vue de réaliser le contrat voulu.
L’un des éléments majeurs de la programmation orientée objet est qu’une classe peut tout à
fait modifier son implémentation, sans que ceci n’ait de conséquences sur son utilisation (à
condition, bien sûr de respecter le contrat !). Par exemple, nous pourrions très bien décider
que nos points seront représentés, non plus par leurs coordonnées cartésiennes, mais par leurs
coordonnées « polaires » 1 . Bien entendu, il faudrait adapter en conséquences le corps des
méthodes, lesquelles devraient conserver leur signature et leur signification : autrement dit,
initialise devrait continuer à recevoir des coordonnées cartésiennes. Il va de soi qu’ici,
une telle modification paraîtrait fortement fantaisiste puisqu’elle entraînerait des complications inutiles. Mais, imaginez une classe Point plus riche dotée de méthodes travaillant, les
unes en coordonnées cartésiennes, les autres en coordonnées polaires. Dans ces conditions, il
faudrait bien sûr trancher dans le choix des attributs entre coordonnées cartésiennes ou coordonnées polaires. Mais ceci n’aura pas de répercussion sur l’interface de la classe. Si celle-ci
1. En coordonnées polaires, un point est caractérisé par sa distance à l’origine (rayon vecteur) et l’angle que fait le
segment joignant l’origine au point avec l’axe des abscisses.
CHAPITRE 9
186
{ retourne abs
}
entier méthode valeurOrd
{ retourne ord
}
On peut alors légitimement se poser la question de l’intérêt d’encapsuler les attributs si on
peut les connaître ou les modifier à volonté à l’aide de méthodes d’accès ou d’altération.
Pourquoi ne pas en autoriser l’accès direct ? En fait, la réponse réside dans la distinction
entre ce que l’on nomme l’interface d’une classe et son implémentation et dont nous allons
parler maintenant.
3.2 Notions d’interface, de contrat et d’implémentation
L’interface d’une classe corresond aux informations dont on doit pouvoir disposer pour pouvoir l’utiliser. Il s’agit :
• du nom de la classe ;
• de la signature (nom de la fonction et type des paramètres) et du type du résultat éventuel
de chacune de ses méthodes.
Dans le cas de notre classe Point, ces informations pourraient se résumer ainsi :
classe Point
{ méthode initialise (entier, entier)
méthode déplace (entier, entier)
méthode affiche
}
Le contrat d’une classe correspond à son interface et à la définition du rôle de ses méthodes.
Enfin, l’implémentation d’une classe correspond à l’ensemble des instructions de la classe,
écrites en vue de réaliser le contrat voulu.
L’un des éléments majeurs de la programmation orientée objet est qu’une classe peut tout à
fait modifier son implémentation, sans que ceci n’ait de conséquences sur son utilisation (à
condition, bien sûr de respecter le contrat !). Par exemple, nous pourrions très bien décider
que nos points seront représentés, non plus par leurs coordonnées cartésiennes, mais par leurs
coordonnées « polaires » 1 . Bien entendu, il faudrait adapter en conséquences le corps des
méthodes, lesquelles devraient conserver leur signature et leur signification : autrement dit,
initialise devrait continuer à recevoir des coordonnées cartésiennes. Il va de soi qu’ici,
une telle modification paraîtrait fortement fantaisiste puisqu’elle entraînerait des complications inutiles. Mais, imaginez une classe Point plus riche dotée de méthodes travaillant, les
unes en coordonnées cartésiennes, les autres en coordonnées polaires. Dans ces conditions, il
faudrait bien sûr trancher dans le choix des attributs entre coordonnées cartésiennes ou coordonnées polaires. Mais ceci n’aura pas de répercussion sur l’interface de la classe. Si celle-ci
1. En coordonnées polaires, un point est caractérisé par sa distance à l’origine (rayon vecteur) et l’angle que fait le
segment joignant l’origine au point avec l’axe des abscisses.