Ce cours initie aux bases de la programmation en utilisant le langage Java : variables, boucles, fonctions, ... Il ne présuppose pas de connaissance préalable. Les aspects plus avancés (programmation orientée objet) sont donnés dans un cours suivant, «Introduction à la programmation orientée objet (en Java)». Il s'appuie sur de nombreux éléments pédagogiques : vidéos sous-titrées, quizz dans et hors vidéos, exercices, devoirs notés automatiquement, notes de cours.
Fonctions : passage des arguments
Loading...
En provenance du cours de École Polytechnique Fédérale de Lausanne
Initiation à la programmation (en Java)
231 notes
À partir de la leçon
Fonctions / Méthodes
Cette semaine aborde un sujet fondamental en programmation : les « fonctions » qui permettent de beaucoup mieux structurer les programmes et d'éviter d'avoir à récrire plusieurs fois la même portion de code.
Rencontrer les enseignants
Jean-Cédric ChappelierDr.
School of Computer and Communication Sciences
Jamila SamDr
School of Computer and Communication Sciences
[AUDIO_VIDE] Dans une séquence précédente,
nous avons examiné les différentes étapes qui se déroulent lorsqu'on appelle
une méthode.
Dans les exemples, vus jusqu'alors, les arguments passés à la méthode étaient soit
de simples valeurs, soit des expressions à évaluer.
Nous allons maintenant affiner un petit peu le discours, et voir ce qu'il se passe
lorsque l'argument passé à la méthode est une variable et en particulier,
dans la situation où la méthode modifie le paramètre, qui lui est passé.
Donc, nous allons nous placer dans une situation concrète suivante.
Supposons par exemple que nous soyons dans un programme principal
qui déclare une variable v1, du même type que celui attendu par la méthode.
Nous invoquons ensuite la méthode en lui passant un argument, la variable v1.
Nous avons vu lors de la dernière séquence, que v1 était copiée dans v,
et cette méthode a pour vocation de tenter, ou de modifier plutôt v.
Donc, la question que nous nous posons concrètement,
maintenant, c'est au sortir de cette méthode, est-ce que la variable v1,
déclarée dans ce programme principal, sort modifiée ou pas de ce traitement?
En programmation de façon générale,
on dira que v est passé par valeur si la réponse à cette question est non.
Et on dira, a contrario,
que v est passé par référence si la réponse à la question est oui.
Dans le cas du passage par valeur, ce qui se produit est que la méthode va
travailler sur une copie locale de l'argument qui lui est passé, v1.
Donc, au moment de l'appel, lorsqu'on réalise cet appel,
la variable v1 est tout simplement copiée dans une
zone locale, v, qui est locale à la fonction.
Et toute altération de cette zone locale n'a aucune incidence sur
la variable d'origine.
En Java, nous allons nous poser cependant la question de que signifie modifier v,
concrètement.
Car la réponse à cette question va dépendre de la nature du type.
Lors d'une séquence antérieure sur les types, nous avons vu qu'en Java,
les données de types élémentaires n'étaient pas manipulées de la même
façon que les données de types évolués.
Donc, type évolué,
on peut par exemple penser aux tableaux ou aux chaînes de caractères.
Par conséquent, si je suis en train de manipuler une donnée de type élémentaire,
modifier v n'a qu'une seule interprétation possible,
si je tente de modifier v en lui affectant une valeur différente, il est clair que
désormais la zone mémoire, nommée v, va contenir une valeur distincte
de ce qu'était sa valeur précédente, la valeur 10, en l'occurrence ici.
Par contre, si je suis en train de travailler avec des données de types
évolués, le discours est différent.
Nous avons vu qu'en effet, les valeurs de types évolués étaient
manipulées via des référence, via des indirections.
Si je manipule une donnée de type String,
par exemple, je ne manipule pas directement la chaîne de caractères,
mais je manipule une référence vers la chaîne de caractères.
Par conséquent, lorsque je parle de modifier v,
qu'est-ce que ça signifie exactement.
Suis-je en train de modifier la référence?
Suis-je en train de modifier la zone mémoire pointée par la référence?
Plaçons-nous maintenant dans la situation
où notre méthode prend en paramètres une donnée de type évolué.
Par exemple, on peut imaginer que type corresponde à un tableau d'entiers,
dans ce cas, la référence v est une indirection,
une référence, vers un tableau d'entiers, qu'on peut schématiser de cette façon-là.
Il y a donc 2 possibilités de modification ici.
Celle qui vient peut-être le plus naturellement à l'esprit,
consiste à mettre une valeur alternative dans v, ce qui veut dire qu'on est en
train de modifier la référence elle-même, ce qui aurait pour incidence, puisqu'ici
je change la référence elle-même, de faire pointer v vers un autre tableau.
Deuxième possibilité de modification, je peux via la référence
modifier l'objet référencé, par exemple écrire ceci, ce qui
aura pour conséquence d'altérer la seconde entrée du tableau de cette façon-là.
Il y a donc en Java, 2 questions à se poser au lieu d'une.
Première question, si ma méthode altère la référence, est-ce que la variable,
la référence passée en argument se trouve modifiée au sortir de la méthode?
Deuxième question, si je modifie l'objet référencé
par v1, via v, est-ce que l'objet référencé par v1 est modifié?
Alors, il faut savoir qu'en Java,
il n'existe en réalité que le passage par valeur.
Ce qui signifie concrètement qu'une méthode travaille toujours
systématiquement qu'avec une copie de l'argument,
qui lui est passé au moment de l'appel.
Dans les cas de types évolués, c'est donc bien une référence qui est copiée.
Si je me place ici dans une situation concrète, où j'ai une méthode m, ici, sans
type de retour, qui prend en paramètre une donnée d'un type quelconque, nommé x.
Supposons par exemple que dans un programme principal,
j'invoque cette méthode de la façon suivante, je déclare une donnée val
du bon type, et ensuite j'appelle ma méthode en lui passant en argument val.
Alors, il faut savoir qu'à ce moment-là,
la valeur de val est copiée dans une zone locale à la méthode.
Donc, reprenons notre question de départ,
en s'intéressant au cas où type est un type élémentaire.
Donc, par exemple, on peut imaginer que type correspond au type entier,
int, et donc le traitement modifiant v pourrait être simplement,
ici, une incrémentation de cette nature-là.
Dans notre programme principal,
v1 serait déclaré de type entier, en lui affectant une valeur d'origine.
Et on invoquerait la méthode sur v1.
Donc, ici, en l'occurrence, nous nous trouvons avec une variable v1
qui contient la valeur 3, et au moment où cet appel est réalisé,
v1 est en fait copié dans une zone locale à la méthode, qui s'appelle v.
Donc, ici, on aurait une copie de la valeur.
Si on exécute ensuite le corps de la méthode,
on altérerait le contenu de v, puisqu'on est en train de travailler sur v.
Et on voit qu'à nul moment, la valeur v1 n'est concernée par cette modification.
Donc, dans le cas où le type est élémentaire,
la réponse à cette question est non en raison du passage par valeur.
Donc, plaçons-nous maintenant dans la situation où notre méthode travaille
avec une donnée de type évolué.
Prenons en guise de type évolué, par exemple un tableau d'entiers.
Donc, ici, dans notre programme principal,
nous écririons quelque chose qui ressemble à ceci.
Ici, nous nous trouvons en mémoire dans la situation suivante, donc,
nous avons une variable v1 qui contient une référence,
en quelque sorte l'adresse vers le tableau 1, 2, 3.
Donc, au moment où est réalisé cet appel de méthode, nous avons vu qu'en Java,
on ne connaît que le passage par valeur, ce qui signifie que
v1 va être copiée dans une zone locale v, locale à la méthode.
Donc, ici, nous avons une zone mémoire v, locale à la méthode et dans laquelle
nous allons copier le contenu de v1, c'est-à-dire la référence vers le tableau.
On voit bien ici qu'autant v que v1 pointent vers le même tableau en mémoire.
Ceci signifie que si par exemple je tente maintenant de modifier l'objet
référencé via v, donc si j'essaye dans la méthode de faire ceci.
Donc, ici, je modifie le tableau via ce lien,
mais puisqu'autant v que v1 pointent vers le même emplacement,
les modifications faites via v, sont visibles via v1.
Ceci donc signifie que dans le cas, où je réalise un traitement dans la
méthode qui modifie l'objet référencé, la réponse à cette question est oui.
Donc, intéressons-nous maintenant à la seconde situation, essayons de réaliser
un traitement qui modifie dans la méthode la référence elle-même.
Donc, ici, du fait du passage par valeur, au moment de cet appel,
nous avons toujours une copie de v1 dans v.
Ce qui signifie que nous sommes dans cette situation-là,
où nous avons copié la référence dans v, la référence vers le tableau dans v.
Maintenant, tentons de modifier cette référence, donc ceci peut se faire par
exemple de cette façon-là, je déclare un autre tableau t, qui a d'autres valeurs,
et je modifie la référence elle-même donc, je réalise cette affectation-là.
Donc, ici, je suis dans cette situation-là en mémoire,
j'ai donc une variable t qui contient une référence vers un autre tableau,
j'ai donc ce lien, et je fais cette affectation qui signifie que j'altère la
référence elle-même, ce qui veut dire que je casse ce lien, le lien n'existe plus.
Désormais, ma variable locale pointe vers le tableau référencé par t.
On voit On voit donc que par le biais de cette manipulation, comme on a modifié la
référence sur une copie locale, v1 n'est nullement affecté par cette modification.
Lorsque je termine d'exécuter ma méthode, donc à ce point là,
j'ai toujours au sein de v1 la valeur adresse.
Ce qui signifie concrètement
que si je réalise un traitement qui modifie la référence elle-même,
la réponse à cette question demeure non, toujours en raison du passage par valeur.
Illustrons maintenant cette discussion sur des cas concrets, des exemples concrets.
Donc nous avons ici à faire à un petit programme principal qui commence par
déclarer une variable val.
Cette variable est de type élémentaire, de type int,
ce qui signifie que la valeur qui lui est associée est directement stockée dans val,
il n'y a pas d'indirections, pas de références.
La seconde instruction invoque une méthode m en lui passant en argument val.
Nous avons vu qu'en JAVA il n'existe que le passage par valeur,
ce qui veut signifie que la valeur de val est copiée dans une zone
locale à la méthode, qui s'appelle ici x.
Donc nous nous trouvons dans la situation où x contient la même valeur que x,
mais il s'agit d'une autre zone en mémoire.
Ensuite s'exécute la première instruction du corps de la méthode, qui a pour rôle
d'incrémenter la valeur de x, donc nous nous trouvons avec la valeur deux pour x,
et lorsqu'on fait afficher la valeur de x,
on voit bien qu'il s'agit bien de la valeur deux.
Ensuite lorsque la méthode a bien terminé son exécution, si l'on veut faire afficher
la valeur de val, on réalise bien que cette valeur est demeurée inchangée.
Elle n'a pas été modifiée en raison du passage par valeur.
Tout ceci pour dire que les modifications dans ce cas de figure qui sont
effectuées à l'intérieur de la méthode
en se répercutent pas sur la variable extérieure val.
Autre situation,
celle de la modification d'une référence dans le corps d'une méthode :
ici nous nous trouvons dans la situation où nous avons un programme principal qui
déclare une variable tab qui est de type évolué, c'est un tableau d'entier.
Donc les types évolués sont manipulés via des interactions,
nous nous retrouvons donc en mémoire dans cette situation là où tab
pointe vers un tableau qui en l'occurrence conteint une seule cellule contenant un.
Ensuite il y a l'appel de la méthode m qui est exécutée.
Et nous avons vu qu'il n'y a que du passage par valeur en JAVA ce qui signifie
que tab est copié dans une zone locale à la méthode qui est x.
Donc nous nous trouvons maintenant dans cette situation où nous avons copié la
valeur de tab dans x, et donc x pointe vers le même tableau en mémoire.
En exécutant le corps de la méthode, la première instruction
rencontrée est celle créant un nouveau tableau.
Ce dernier va donc pointer vers un nouveau tableau en mémoire avec une autre
référence, qui en l'occurrence conteint une seule et unique cellule valant cent.
Et la seconde instruction tente d'altérer la référence elle-même.
Donc on affecte à x l'adresse du nouveau tableau.
Ce qui a pour conséquence de casser ce lien
et d'en créer un nouveau vers ce tableau.
Si maintenant on fait afficher la valeur de la première cellule du tableau x,
x de zéro, étant donné le lien nouvellement créé vaut clairement cent.
Lorsque la méthode a terminé son exécution,
et qu'on fait afficher la valeur de la première cellule du tableau tab,
on voit que l'altération faite sur la référence elle-même n'est nullement
visible sur l'argument, en raison du passage par valeur,
et du coup la valeur de tab de zéro reste inchangée et vaut toujours donc un.
Donc le résultat de l'exécution de ce programme nous montre que
les modifications faites dans la méthode sur la référence elle-même ne sont
pas visibles à l'extérieur de la méthode, toujours en raison du passage par valeur.
Dernière situation,
celle de la modification de l'objet référencé dans le corps d'une méthode.
Donc nous nous trouvons dans la même situation que
celle de l'exemple précédent,
où le programme principal créé un tableau contenant une seule cellule valant un.
Au moment de l'appel de la méthode m, en lui passant l'argument tab,
en raison toujours du passage par valeur, tab est copié dans x,
x qui est une zone locale à la méthode m.
Nous voyons bien qu'ici, autant tab que x référence le même tableau.
Donc ici en exécutant le corps de la méthode m, la première instruction
rencontrée va altérer la première cellule du tableau pointée par x.
Ce qui aura pour effet de modifier cette cellule.
Et nous voyons que la modification faite sur la première cellule du tableau x
est également visible dans tab.
Donc l'exécution de cet instruction d'affichage va clairement afficher
que x zéro a pour valeur cent.
Lorsque nous terminons l'exécution de la méthode et passons à l'affichage suivant,
étant donné qu'aussi bien tab que x pointent vers le même tableau,
l'affichage de la valeur de tab de zéro sera également cent.
Donc la situation ici est que la modification faite
à l'intérieur de la méthode est également visible à l'extérieur de la méthode
en dépit du passage par valeur.
Pourquoi? Parce qu'aussi bien la zone locale à la
méthode que celle de l'argument pointent en réalité sur le même tableau.
Explorer notre catalogue
Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.
Coursera propose un accès universel à la meilleure formation au monde,
en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.
© 2019 Coursera Inc. Tous droits réservés.
