Ce chapitre illustre et décrit le mécanisme d'envoi de messages qui est à la base de l’interaction entre les objets. Cette interaction exige que les classes dont sont issus ces objets entre dans un rapport de composition, d'association ou de dépendance.
Envois de message, les objets interragissent, et comme tout ce qu'ils font dit être prévu dans leurs classes, celles-ci se doivent d'interagir également. C'est cette interaction entre objets, lorsqu'un d'entre eux demande à l'autre d'exécuter une méthode, qui constitue le mécanisme clé et récurrent de l'exécution d'un programme OO. Un tel programme n'est finalement qu'une longue suite d'envois de message entre les objets agrémentés ici et là de quelques mécanismes procéduraux (tests conditionnels, boucles ...).
Nous allons, à l'aide d'un exemple minimal de programmation, illustrer ce principe de communication entre deux objets. Supposons un premier objets o1, instance d'une classe01, contenant la méthode jeTravaillePour01( ), et un deuxième objet o2, contenant la méthode jeTravaillePour02( ). Dans le logiciel, o1 interagira avec o2, si la méthode jeTravaillePour01( ) contient un instruction pour que l'objet o1 interfére avec l'objet o2. Mais, pour que o1 puisse exécuter quoi que ce soit, il faudra d'abord chercher la méthode jeTravaillePour01( ) sur o1. Nous supposerons que la méthode main s'en charge et débute l'exécution du programme en déclenchant la méthode jeTravaillePour01( ) sur l'objet o1. Comme ci-dessous.
Dans ce diagramme (il s'agit en fait d'un diagramme de séquence UML), le petit bonhomme fait office de main, en envoyant le premier message jeTravaillePour01( ) sur l'objet o1. Par la suite, nous voyons que l'objet o1 interrompt l'exécution de sa méthode, le temps pour o2 d'exécuter la sienne. Finalement le programme reprendra normalement son cours, là où il l'a abandonné, en redonnant la main à o1. L'envoi de message s'accompagne d'un passage de relais de l'objet o1 à l'objet o2, relais qui sera restitué à o1 une fois qu'o2 en aura terminé avec sa méthode.
Association de classes, Si o1 déclenche la méthode jeTravaillePour02( ) sur l'objet o2, c'est que la classe responsable de o1 sait que cet objet o2 est à même de pouvoir exécuter cette méthode. Pour ce faire, la classe o1 se doit d'être informée, quelque part dans son code, sur le type de l'objet o2, c'est-dire la classe o2. Une première manière pour la classe o1 de connaître la classe o2 est celle indiquée ci-dessous(il s'agit à nouveau d'un diagramme UML, cette fois de classe).
On dira dans ce cas que les deux classes sont associées et que la connaissance de o2 devient une donnée structurelle à part entière de la classe o1. En langage de programmation, o2 devient purement et simplement le type d'un attribut de o1, comme dans le code de la classe qui suit :
class 01{
02 lien02 ; /* la classe 02 type un attribut de la classe 01 */
void jeTravaillePour01() {
lien02.jeTravaillePour02() ;
}
}
Comme tout autre attribut de type « primitif », cet attribut lienO2 devient accessible dans l'entièreté de la classe. Il s'agit en fait d'une espèce nouvelle d'attribut dit « attribut référent », typé, non plus par un type primitif, mais bien par la classe qu'il réfère. Dans l'espace mémoire réservé à o1, l'attribut lienO2 contiendra, l'adresse de l'objet o2. C'est qui lui permettra d'entrer directement en communication avec o2.
La manière privilégiée pour permettre à deux classes de communiquer par envoi de message consiste à rajouter aux attributs primitifs de la première un référent du type de la seconde. La classe peut donc, tout à la fois, contenir des attributs et se constituer en nouveau type attribut. C'est grâce à ce mécanisme de typage particulier que, partout dans son code, la première classe pourra faire appel aux méthodes disponibles de la seconde.
Dépendance de classes, il existe d'autres manières, non persistantes cette fois, pour la classe 01de connaître le type 02. Comme dans le code qui suit, la méthode jeTravaillePour01(02 lien02) pourrait recevoir comme argument l'objet o2, sur lequel il est possible de déclencher la méthode jeTravaillePour02( ).
class 01{
void jeTravaillePour01(02 lien02) {
lien02.jeTravaillePour02() ;
}
}
Le compilateur acceptera le message car le destinataire est bien typé par la classe 02. Cependant, dans un cas semblable, le lien entre 01 et 02 n'aura d'existence que le temps d'exécution de la méthode jeTravaillePour01( ), et on parlera, entre les deux classes, plutôt que d'un lien d'association, d'un lien de dépendance, plus failble et surtout passager. Dans le diagramme de classe UML, le lien passe de « plein » à « pointillé ».
Les deux classes ne connaissent dès lors que durant le temps d'exécution de la méthode. Un lien de dépendance est maintenu entre les deux classes, car toute modification de la classe qui fournit la méthode à utiliser pourrait entraîner une modification de la classe qui fait appel à cette méthode. Il s'agit à proprement parler plutôt d'une dépendance de type logicielle, car elle reste au niveau de l'écriture logicielle des deux classes, alors que le lien d'association va bien au-delà de cette dépendance, et représente une véritable connexion structurelle et fonctionnelle entre ces deux classes.
Un autre liaison passagère pourrait se produire, si, comme dans le code ci-après la méthode jeTravaillePour01( ) décide, tout de go, de créer l'objet lien02, le temps de l'envoi du message.
class 01{
void jeTravaillePour01() {
02 lien02 = new 02
lien02.jeTravaillePour02() ;
}
}
Au sortir de la méthode, l'objet lien02 sera irrémédiablement perdu, de même que cette liaison passagère qui, là encore, n'aura duré que le temps d'exécution de la méthode jeTravaillePour01( ).En Java et C# le seul référent étant à nouveau stocké en mémoire pile, la méthode terminée, ce référent disparaîtra emportant à sa suite le seul objet référé par lui.Alors que, dans le première dépendance, c'est la liaison entre les deux objets qui s'interrompait à la fin de la méthode, ici l'objet du message s’éclipsera également à la fin de cette méthode.Autant que faire se peut, on privilégiera entre les classes des liens de type fort, d'association, faisant des relations entre les classes une donnée structurelle de chacune d'entre elles.
Communication possible entre objets, deux objet pourront communiquer si les deux classes correspondantes possèdent entre elles une liaison de type composition, association, ou de dépendance, la force et la durée de la liaison allant décroissant avec let type de liaison. La communication sera dans les
liaisons de type composition et ou association possible, quelle que soit l'activité entreprise par le premier objet, alors que dans
les liaisons de type dépendance elle se déroulera uniquement durant l'exécution des seules méthodes du premier objet, qui recevront de façon temporaire un référent du second.
Aucun commentaire:
Enregistrer un commentaire