Composition des objets
CHAPITRE 11
238
Écrire une classe nommée Quadrilatère, permettant de manipuler des quadrilatères, définis par 4 points, dotée d’un constructeur (recevant un tableau de 4 points en paramètre),
d’une méthode affiche fournissant les coordonnées de chacun des 4 points du quadrilatère
et d’une méthode déplace (déplaçant de la même manière les 4 points du quadrilatère).
3 Relations entre objets
Nous venons de voir que définir un attribut de type classe n’est pas quelque chose d’aussi
anodin que d’utiliser un attribut d’un type de base. En effet, cet attribut n’est en fait qu’une
référence à un autre objet, ce que l’on peut schématiser ainsi de façon générale :
La question peut alors se poser de savoir si l’objet B peut exister, indépendamment de A ou
non. En fait, comme on l’a entrevu dans les exemples précédents, la situation diffère selon
que B a été créé par A (en général par son constructeur, mais il pourrait aussi s’agir d’une
méthode) ou si sa référence a simplement été communiquée à A par le programme.
Dans le premier cas, lorsque l’objet A ne se trouve plus référencé, il en ira probablement de
même de B (sauf si A en a communiqué la référence à « l’extérieur »). On traduit souvent
cette situation en disant que A possède B ; par exemple, on pouvait dire qu’un segment possédait deux points. Dans le second cas, en revanche, il est possible que A ne soit plus référencé alors que B l’est encore. On dit que A ne possède pas B. Dans nos deux exemples de
classe Cercle, selon le constructeur utilisé, un cercle possèdait un point dans le premier cas
et pas dans le second (et nous avions illustré la première situation par un schéma montrant
mieux cette appartenance).
Comme nous l’avons montré, dans les langages gérant les objets, l’existence d’un attribut de
type objet conduit systématiquement à une relation de possession (quitte à ce que l’objet possédé soit en fait une copie d’un autre).
D’une manière générale, cette relation de possession joue un rôle important en programmation orientée objet. On dit souvent qu’elle traduit la relation « a » (du verbe avoir) et nous
verrons qu’elle doit être clairement différenciée de la relation « est » (du verbe être) qui sera
induite par l’héritage.
Objet A
Objet B
CHAPITRE 11
238
Écrire une classe nommée Quadrilatère, permettant de manipuler des quadrilatères, définis par 4 points, dotée d’un constructeur (recevant un tableau de 4 points en paramètre),
d’une méthode affiche fournissant les coordonnées de chacun des 4 points du quadrilatère
et d’une méthode déplace (déplaçant de la même manière les 4 points du quadrilatère).
3 Relations entre objets
Nous venons de voir que définir un attribut de type classe n’est pas quelque chose d’aussi
anodin que d’utiliser un attribut d’un type de base. En effet, cet attribut n’est en fait qu’une
référence à un autre objet, ce que l’on peut schématiser ainsi de façon générale :
La question peut alors se poser de savoir si l’objet B peut exister, indépendamment de A ou
non. En fait, comme on l’a entrevu dans les exemples précédents, la situation diffère selon
que B a été créé par A (en général par son constructeur, mais il pourrait aussi s’agir d’une
méthode) ou si sa référence a simplement été communiquée à A par le programme.
Dans le premier cas, lorsque l’objet A ne se trouve plus référencé, il en ira probablement de
même de B (sauf si A en a communiqué la référence à « l’extérieur »). On traduit souvent
cette situation en disant que A possède B ; par exemple, on pouvait dire qu’un segment possédait deux points. Dans le second cas, en revanche, il est possible que A ne soit plus référencé alors que B l’est encore. On dit que A ne possède pas B. Dans nos deux exemples de
classe Cercle, selon le constructeur utilisé, un cercle possèdait un point dans le premier cas
et pas dans le second (et nous avions illustré la première situation par un schéma montrant
mieux cette appartenance).
Comme nous l’avons montré, dans les langages gérant les objets, l’existence d’un attribut de
type objet conduit systématiquement à une relation de possession (quitte à ce que l’objet possédé soit en fait une copie d’un autre).
D’une manière générale, cette relation de possession joue un rôle important en programmation orientée objet. On dit souvent qu’elle traduit la relation « a » (du verbe avoir) et nous
verrons qu’elle doit être clairement différenciée de la relation « est » (du verbe être) qui sera
induite par l’héritage.
Objet A
Objet B