Les objets locaux et leur durée de vie
207
Dans ce cas, une affectation telle que a := b (a et b étant deux objets du type Point) effectue une recopie de l’ensemble des valeurs des attributs de b dans ceux de a.
On notera qu’ici, le principe d’encapsulation n’est pas vraiment mis en défaut, dans la
mesure où cette recopie concerne tous les attributs de l’objet, attributs que l’utilisateur n’a
pas à connaître cette fois ; en particulier, il n’aura rien à changer en cas de modification
d’implémentation de la classe, même si celle-ci en modifie les attributs.
Des considérations semblables s’appliquent à la comparaison d’objets : dans les langages utilisant la gestion par valeur, la comparaison porte sur les valeurs des attributs ; deux objets
différents ayant les mêmes valeurs d’attributs apparaîtront égaux :
Point a (3, 8), b(3, 8)
si (a = b) ...... // dans un langage gérant les objets par valeur,
// cette relation sera vraie
2 Les objets locaux et leur durée de vie
Nous avons expliqué ce qu’était une variable locale à une fonction et nous avons vu que cette
propriété se généralisait tout naturellement aux méthodes d’une classe.
Par ailleurs, comme on peut s’y attendre, il est possible de définir des variables locales de
type objet. Par exemple, dans une fonction f, nous pouvons déclarer une variable locale de
type Point :
f (.....)
{ Point p
.....
}
Il en va de même dans une méthode, avec cette différence qu’on pourra distinguer deux cas
selon qu’il s’agit d’une variable d’un type objet de la classe à laquelle elle appartient ou d’un
type différent. Cet aspect n’aura pas d’incidence sur notre propos ici (nous verrons plus loin
qu’il en aurait sur l’accès que la méthode pourrait avoir aux attributs de l’objet correspondant).
Dans tous les cas, il faut bien comprendre que l’on a affaire à une variable de type objet,
c’est-à-dire destinée à recevoir une simple référence à un objet. L’objet concerné devra être
créé par ailleurs (il peut même y avoir plusieurs objets à créer si la référence varie au fil de
l’exécution de la fonction). On pourra se trouver dans cette situation :
f (.....)
{ Point p
.....
p = Création Point (...)
.....
}
Et là se pose la question de la « durée de vie » de la variable p d’une part, de l’objet référencé
d’autre part. La variable p, comme toute variable locale n’existera plus après la sortie de la
fonction. En revanche, dans tous les langages objet (à gestion par référence), l’objet lui-
207
Dans ce cas, une affectation telle que a := b (a et b étant deux objets du type Point) effectue une recopie de l’ensemble des valeurs des attributs de b dans ceux de a.
On notera qu’ici, le principe d’encapsulation n’est pas vraiment mis en défaut, dans la
mesure où cette recopie concerne tous les attributs de l’objet, attributs que l’utilisateur n’a
pas à connaître cette fois ; en particulier, il n’aura rien à changer en cas de modification
d’implémentation de la classe, même si celle-ci en modifie les attributs.
Des considérations semblables s’appliquent à la comparaison d’objets : dans les langages utilisant la gestion par valeur, la comparaison porte sur les valeurs des attributs ; deux objets
différents ayant les mêmes valeurs d’attributs apparaîtront égaux :
Point a (3, 8), b(3, 8)
si (a = b) ...... // dans un langage gérant les objets par valeur,
// cette relation sera vraie
2 Les objets locaux et leur durée de vie
Nous avons expliqué ce qu’était une variable locale à une fonction et nous avons vu que cette
propriété se généralisait tout naturellement aux méthodes d’une classe.
Par ailleurs, comme on peut s’y attendre, il est possible de définir des variables locales de
type objet. Par exemple, dans une fonction f, nous pouvons déclarer une variable locale de
type Point :
f (.....)
{ Point p
.....
}
Il en va de même dans une méthode, avec cette différence qu’on pourra distinguer deux cas
selon qu’il s’agit d’une variable d’un type objet de la classe à laquelle elle appartient ou d’un
type différent. Cet aspect n’aura pas d’incidence sur notre propos ici (nous verrons plus loin
qu’il en aurait sur l’accès que la méthode pourrait avoir aux attributs de l’objet correspondant).
Dans tous les cas, il faut bien comprendre que l’on a affaire à une variable de type objet,
c’est-à-dire destinée à recevoir une simple référence à un objet. L’objet concerné devra être
créé par ailleurs (il peut même y avoir plusieurs objets à créer si la référence varie au fil de
l’exécution de la fonction). On pourra se trouver dans cette situation :
f (.....)
{ Point p
.....
p = Création Point (...)
.....
}
Et là se pose la question de la « durée de vie » de la variable p d’une part, de l’objet référencé
d’autre part. La variable p, comme toute variable locale n’existera plus après la sortie de la
fonction. En revanche, dans tous les langages objet (à gestion par référence), l’objet lui-