Passage de paramètres en out

Salut,
je ne me rappelle plus trop de ce langage, j'ai une question sur mon code que je vais ici simplifier à l'extrême pour pas tout vous copier coller :

méthode principale

Code:

---

1 2 3 4 5 6

{ String a = "ok"; String b = "ok2"; change(a,b); // ici quelles sont les valeurs de a et b ? "ok" ou "changé" ? }

---

et la méthode change :

Code:

---

1 2 3 4

public void change(String a, String b) { a= "changé"; b="changé2"; }

---

Est-ce que avec cette méthode en void ça va me changer les valeurs des string dans la méthode où a lieu l'appel ?
Si oui, ok.
Si non, comment faire pour récupérer ces 2 modifs avec l'appel de la méthode ?

Merci à vous

salut,

tes objets String seront modifiés, puisque java ne travaille qu'avec des références, et donc ce sont les références de tes String qui sont passés comme arguments à la méthode change(...), et seront directement modifiés.
mais tu aurais pu simplement faire un System.out.println(a + ", " + b) pour tester !!

Bonjour,

Je suis pas d'accord Herch, au contraire, les valeurs restent inchangées, tu auras donc a = "ok" et b = "ok2"

Tes valeurs n'auront pas changé. Les valeurs de a et b resteront "ok et "ok2".

ok merci !

sinon par curiosité, si je veux passer un paramètre String comme ça, mais que je ne veux pas qu'il soit modifié dans la méthode appelante (alors qu'il y a une modif dans la méthode appelée) je fais comment ? (càd que a ou b gardent leurs valeurs "ok" et "ok2" après l'appel). A part une copie ds une string différente avant l'appel il existe qlqch d'autre ?

Ps : il m'était plus simple de demander sur un forum que de faire un println car je suis sur un projet énorme et ma partie ne se lance qu'en cas d'exceptions rares... et je ne sais pas la déclencher pour l'instant car j'arrive à peine sur ce projet :mrgreen: enfin bref.

ah mince javais pas vu les 2 autres réponses.
comment faire alors ? pour qu'elles changent ?

Tu ne peux pas les faire changer, en effet String est un objet immuable.

Il faut soit que la méthode retourne les infos qui t'intéressent
ou plutot utiliser des StringBuilder.

ah ... :cry: dommage ça

je fais comment du coup ?

Code:

---

1 2 3 4 5 6 7 8 9 10

public String[] change(String a, String b) { a= "changé"; b="changé2";   String[] st; st[0] = a; st[1] = b;   return st; }

---

et dans la méthode appelante :

Code:

---

1 2 3

String[] result = change(a,b); a = result[0]; b = result[1];

---

ça marche ça ? :roll:

ou déclare ta methode et tes String en instance de classe (static) pour que les valeurs soient changées.

Citation:

---

Envoyé par MuLog

ah ... :cry: dommage ça

je fais comment du coup ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public String[] change(String a, String b) { a= "changé"; b="changé2";   String[] st; st[0] = a; st[1] = b;   return st; }

---

et dans la méthode appelante :

Code:

---

1 2 3 4

String[] result = change(a,b); a = result[0]; b = result[1];

---

ça marche ça ? :roll:

---

Oui, ça marche, mais ce n'est pas top, tu ne peux pas avoir une méthode pas valeur de Stirng a changer?

Code:

---

1 2 3 4

String changeA() { return "changé"; }

---

Ou regarde du coté de la classe StringBuilder qui te permettra de passer par référence.
Ou utilise des instances de classes comme la dit blueman1.

:aie:
j'avais oublié que les String étaient immuables

Citation:

---

Envoyé par herch

:aie:
j'avais oublié que les String étaient immuables

---

Que les String ? ça veut dire que ça marche pour les int ? :p

Sinon pour les static, je ne peux pas, je dois suivre un genre de cahier des charges pour cette modif sur le code, et je dois seulement ajouter une méthode sans utiliser d'attributs static.

Et pour le :

Code:

---

1 2 3

String changeA() { return "changé"; }

---

Je ne peux pas non plus, car du coup il me faudrait 2 méthodes. ChangeA et B. Et le but de ma modif est de synthétiser le code pour écrire le moins de lignes possible, je pense que le tableau String[] est mieux à ce niveau là

tu pourrais utiliser StringBuilder comme il a été dit

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

public class TestString { static void changer(StringBuilder s1, StringBuilder s2) { s1.replace(0, s1.length(), "changé"); s2.replace(0, s2.length(), "changé2"); } public static void main(String[] args) { StringBuilder s1 = new StringBuilder("ok"); StringBuilder s2 = new StringBuilder("ok2"); System.out.println("Avant : " + s1 + ", " + s2); changer(s1, s2); System.out.println("Après : " + s1 + ", " + s2); } }

---

pour les types primitifs comme le int, float ..., ça marche pas, ils sont passé par valeur

woua, je ne connaissais pas ça.
merci pour l'info

hmmm l'histoire du passage de paramètres n'a pas grand chose à voir avec le fait que les String soient immuables... c'est plutôt dû au passage des objets en paramètre de façon générale...

J'ai trouvé un lien ici qui explique le passage de paramètres.

Dans la fonction change, tu déclares une variable locale a[*], qui contient une référence vers l'objet String passé en paramètre.
Lorsque tu effectues a="changé" tu crées un nouvel objet String et tu affectes à la variable locale a la référence vers ce nouvel objet, mais tu ne modifies pas l'objet passé en paramètre.
Si la classe String présentait une méthode modifiant l'état interne de l'instance à laquelle elle est appliqué [**], tu aurais effectivement pu modifier "par référence" les objets passés en paramètre, comme dans l'exemple suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

static class TestClass { private int test;   public TestClass(int test) { this.test = test; }   public void setTest(int test) { this.test = test; }   public int getTest() { return test; }   public String toString() { return String.valueOf(test); }   }   public static void reset1(TestClass a) { a = new TestClass(0); }   public static void reset2(TestClass a) { a.setTest(0); }   public static void main(String[] args) { TestClass a = new TestClass(1); TestClass b = new TestClass(1);   System.out.println(a); System.out.println(b);   reset1(a); reset2(b);   System.out.println(a); System.out.println(b); }

---

Résultat :

Code:

---

1 2 3 4

1 1 1 0

---

Et donc pour répondre au problème : pour pouvoir modifier dans une méthode les objets passés en paramètres, il faudrait que ces objets présentent les méthodes permettant de modifier leur état... ce qui n'est pas le cas des String.
Il faut donc trouver une autre méthode, plusieurs ont déjà été proposées, celle qui s'approche le plus de ce que tu voulais faire au départ serait d'utiliser des StringBuilder/StringBuffer tant que tu es susceptible d'y appliquer des modifications et de les transformer en String au dernier moment seulement.
Si tu expliquais de façon plus générale ce que tu cherches à faire, on pourrait peut-être t'aider à trouver une meilleure solution ;)


[*] ça marche aussi pour b bien sûr :mrgreen:
[**]en fait une telle méthode n'existe pas, c'est là qu'il devient pertinent de dire que les String sont immuables ;) mais voyez l'exemple, avec des objets quelconques, c'est pareil !

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

public class TestString { static void changer(StringBuilder s1, StringBuilder s2) { s1.replace(0, s1.length(), "changé"); s2.replace(0, s2.length(), "changé2"); } public static void main(String[] args) { StringBuilder s1 = new StringBuilder("ok"); StringBuilder s2 = new StringBuilder("ok2"); System.out.println("Avant : " + s1 + ", " + s2); changer(s1, s2); System.out.println("Après : " + s1 + ", " + s2); } }

---

Merci Astartee, mais je pense que ce code répond bien à mon problème, seulement à une condition :

- puis-je utiliser s1 et s2 en tant que String normales dans la méthode changer avant de faire la modif avec s1.replace() ?
(c'est à dire faire un println, etc) ou estce que le StringBuilder le transforme en truc bizarre qui n'est pas un String ? ^^

Sinon c'est très compliqué à expliquer mon code... je ne le comprends pas moi même en entier car je reprends du code existant pour faire du "nettoyage"

Tu peux utiliser les variables locales s1 et s2 en tant que StringBuilder (et pas String ;)) et donc oui, bien sûr que tu peux imprimer leur valeur, puisque la méthode toString de cette classe est bien définie et renvoie la chaîne de caractères représentées par l'instance.

Citation:

---

Envoyé par Astartee

[*] ça marche aussi pour b bien sûr :mrgreen:
[**]en fait une telle méthode n'existe pas, c'est là qu'il devient pertinent de dire que les String sont immuables ;) mais voyez l'exemple, avec des objets quelconques, c'est pareil !

---

Oui, 100% d'accord, mais le fait que l'on n'est aucune méthode disponible pour effectuer des modifications sur String et que l'on soit obligé de changer la référence est bien du au fait que String soit immuable.

Citation:

---

Envoyé par Astartee

Si la classe String présentait une méthode modifiant l'état interne de l'instance à laquelle elle est appliqué [**], tu aurais effectivement pu modifier "par référence" les objets passés en paramètre, comme dans l'exemple suivant :

---

Oui, mais dans ce cas String ne serait plus immuable.

Du coup, aucune méthode ne permet de changer l'état interne parce que String est un objet immuable. Si elle ne l'était pas on aurait pu.

Je me trompe?

Citation:

---

Envoyé par eric39

Je me trompe?

---

Nan, c'est bien ça, et c'est très exactement ce que j'ai dit dans ma deuxième note ([**]) ;)

EDIT
Explication de ma phrase "l'histoire du passage de paramètres n'a pas grand chose à voir avec le fait que les String soient immuables" :
Après que herch a été corrigé sur la première question (est-ce que les variables passées en paramètres sont modifiées après l'appel de la fonction change ?), il a dit "j'avais oublié que les String étaient immuables", ce qui donne l'impression que c'est cette immuabilité qui entraîne l'absence de modification, ce qui est faux puisque c'est valable pour n'importe quel objet (cf. mon petit exemple).
Le fait qu'on ne puisse pas effectuer avec des String ce que voulait faire MuLog est par contre bien dû à l'immuabilité des String, puisqu'avec un autre type d'objet (qui propose des méthodes modifiant l'instance elle-même...) ça peut marcher.
(gargl, je m'embrouille, je suis de moins en moins claire en fait :aie:)

Citation:

---

Envoyé par Astartee

Nan, c'est bien ça, et c'est très exactement ce que j'ai dit dans ma deuxième note ([**]) ;)

---

OK, j'avais du coup, eu un doute sur le principe d'objet immuable...;)