Histoire de passage d'argument

Bonjour,

je voudrais créer une fonction qui me retourne une information sous forme d'un entier, et qui me fournit aussi une date correspondant à la valeur de retour; l'exemple sera plus parlant:

Code:

---

1 2 3 4 5 6

int donneEtatEtDate( Date dateTransmise ) { dateTransmise = new Date( uneDateMembrePrive ); / ... / return valeur_en_rapport_avec_date; }

---

uneDateMembrePrivé est un membre privé, je ne veux donc pas donner son instance. Si je programme:

Code:

---

dateTransmise = uneDateMembrePrive

---

ce membre peut alors être modifié par le code qui récupère dateTransmise; est-ce que ce raisonnement est juste ?
Donc j'initialise dateTransmise à l'aide de new() ce qui me donne donc un clone du membre privé et protège donc la donnée privée; est-ce que ce raisonnement est juste ?

Je récupère donc en retour une information, et une date correspondant à cette information; y a-t-il une autre solution à ce genre de problème ?

@ bientôt...

Déjà, il faut savoir qu'en java, on passe les arguments par copie de référence.

Donc, réaffecter dateTransmise dans ta méthode n'affectera pas la valeur utilisée à l'appel de ta méthode. Par contre, tu peux faire si tu veux effectivement modifier l'instance utilisée à l'appel de la méthode :

Code:

---

1 2 3 4 5 6 7

int donneEtatEtDate( Date dateTransmise ) { dateTransmise.setTime(uneDateMembrePrive.getTime()); / ... / return valeur_en_rapport_avec_date; }

---

Explicitons donc que cela n'est possible qu'avec des classes mutables, telles que Date, et impossible avec des classes immutables, telles que String et Integer.

Bonjour Thelvin,

Si j'ai bien compris: la classe Date est mutable, ce qui signifie que si je code:

Code:

---

dateTransmise = uneDateMembrePrive

---

alors uneDateMembrePrive pourra être modifié par le code appelant ?

Donc l'idée de faire:

Code:

---

dateTransmise = new Date( uneDateMembrePrive );

---

est une bonne chose ?

Cette précaution n'est pas nécessaire avec des classe comme String ou Integer, j'ai bon là ?

@ bientôt...

Ou pas.

Une classe Immutable est une classe en lecture seule, donc on ne peut modifier le contenu. Par exemple on ne peut modifier le contenu d'une String.

Une classe Mutable est un classe dont le contenu peut être modifié.

Wow. Et moi qui pensais avoir apporté le dernier élément à clarifier... J'aurais mieux fait de fiche la paix à mon clavier, tiens.

Citation:

---

Envoyé par rtg57

Si j'ai bien compris: la classe Date est mutable, ce qui signifie que si je code:

Code:

---

dateTransmise = uneDateMembrePrive

---

alors uneDateMembrePrive pourra être modifié par le code appelant ?

Donc l'idée de faire:

Code:

---

dateTransmise = new Date( uneDateMembrePrive );

---

est une bonne chose ?

Cette précaution n'est pas nécessaire avec des classe comme String ou Integer, j'ai bon là ?

---

Non. Qu'une classe soit mutable ou immutable n'a pas le moindre effet sur l'opérateur d'assignation.

Ce que je voulais dire, c'est qu'un objet mutable a des méthodes setTruc(), setMachin(), et autres choses qui permettent de modifier son état interne. Ainsi, on peut modifier un objet mutable passé en paramètre.

Par contre, un objet immutable n'a pas de méthode en setTruc() qui permette de changer son état interne, son état interne est constant, parce que c'est ça que ça veut dire, immutable. Bref, comme dirait Lapalisse, on ne peut pas muter un objet immutable, et par conséquent l'astuce du dessus, qui peut être utilisée avec des objets mutables, ne peut pas l'être avec des objets immutables.
Une bonne raison pour organiser son code autrement, de sorte que ça marche dans tous les cas.

Merci à tous pour votre aide.

@ bientôt.

Citation:

---

Envoyé par rtg57

Bonjour Thelvin,

Si j'ai bien compris: la classe Date est mutable, ce qui signifie que si je code:

Code:

---

dateTransmise = uneDateMembrePrive

---

alors uneDateMembrePrive pourra être modifié par le code appelant ?

---

Je le redis pour être sûr quand même : si tu ne renvoies pas dateTransmise, alors de toute façon le code appelant n'aura jamais aucun contact avec uneDateMembrePrive, car la variable du code appelant ne pointera plus vers la même chose que dans le code appelé.