getter, setter et références sur objets

Bonjour,

lorsque j'ai débuté en JAVA, j'avais lu un article concernant la protection des références sur les objets, je crois que cela parlait d'encapsulation.
Sauf que à l'époque, je n'y comprenais pas grand-chose et j'avais d'autres soucis avec JAVA.

Actuellement, je développe une application, dont une classe à des objets et variables membres privés.
Je permets aux autres classes de l'application d'accéder aux valeurs de ces membres, via une interface équipée de getters et setters. Du genre:

Code:

---

1 2 3 4 5 6 7 8 9

public void setNomPrenom( String sNomPrenom ) { this.nomPrenom = sNomPrenom; }   public String getNomPrenom() { return this.nomPrenom; }

---

Comme je commence à comprendre certaines choses en JAVA (enfin c'est ce que je crois :aie: ), j'ai l'impression que ce code n'est pas très sécurisé.
En effet, j'ai lu qu'en JAVA, on transmet des références sur les objets.

1) Dans setNomPrenom( String sNomPrenom ), je transmets une référence sur un objet String, et je copie cette référence dans l'objet membre nomPrenom.
Je pense que dans la classe appelante, celle-là même qui a fourni sNomPrenom, je modifie le contenu de cette chaine de caractères, alors je modifie aussi le contenu de nomPrenom ? Vrai ou Faux ??

2) Dans getNomPrenom(), je transmets une référence sur l'objet membre ( qui est défini comme private), à la classe qui en fait la demande. Celle-ci ayant cette référence, a donc tout loisir de modifier le contenu d'un élément auquel elle ne devrait pourtant pas avoir accès. Vrai ou Faux ??

Je ne retrouve plus l'article traitant de ce sujet, mais je crois qu'aujourd'hui j'en aurais bien besoin :?

Avez-vous des tuyaux à me fournir sur le sujet ?

Merci & @ bientôt...

Alors, déjà, ton exemple est mal choisi...
En effet, les String sont immutables : les méthodes de la classe String ne modifient jamais l'instance à laquelle elles sont appliquées (les méthodes replace ou substring, par exemple, renvoient une nouvelle instance de String).

Par contre, sur le principe, tu as raison.
Si tu donnes directement accès à un objet, tu pourras y appliquer toutes les méthodes de cet objet en question, et donc éventuellement modifier l'état de l'instance concernée.

Exemple:

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 43 44

public class Trucmuche { private List<String> list;   public Trucmuche() { this.list = new ArrayList<String>(); }   public void setList(List<String> list) { this.list = list; }   public List<String> getList() { return this.list; }   public void print() { System.out.println("Liste à " + this.list.size() + " éléments:"); Iterator<String> it = this.list.iterator(); while (it.hasNext()) { System.out.println(it.next()); } System.out.println("----------"); }   public static void main(String[] args) { Trucmuche chose = new Trucmuche(); chose.print();   chose.getList().add("bli"); // j'ajoute un élément à la liste... chose.getList().add("bla"); // j'ajoute un élément à la liste... chose.getList().add("blu"); // j'ajoute un élément à la liste... chose.print(); chose.getList().remove(1); // j'enlève un élément de la liste... chose.print();   List<String> newList = new ArrayList<String>(Arrays.asList(new String[] {"hihi"})); chose.setList(newList); // je remplace la liste... chose.print(); newList.add("huhu"); // j'ajoute un élément à la liste sans même faire référence à chose... chose.print(); } }

---

En donnant directement accès à l'objet list, je permets de faire n'importe quoi avec cet objet.

La solution pour limiter les actions possibles : l'encapsulation

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

public class Trucmuche { private List<String> list;   public Trucmuche() { this.list = new ArrayList<String>(); }   // la seule action externe autorisée sur la liste : l'ajout d'éléments public void addToList(String item) { this.list.add(item); }   public void print() { System.out.println("Liste à " + this.list.size() + " éléments:"); Iterator<String> it = this.list.iterator(); while (it.hasNext()) { System.out.println(it.next()); } System.out.println("----------"); }   public static void main(String[] args) { Trucmuche chose = new Trucmuche(); chose.print();   chose.addToList("bli"); // j'ajoute un élément à la liste... chose.addToList("bla"); // j'ajoute un élément à la liste... chose.addToList("blu"); // j'ajoute un élément à la liste... chose.print(); } }

---

Ici, j'ai encapsulé la fonction "ajout d'un élément à la liste" dans la méthode addToList, et c'est la seule action que je présente à l'extérieur de ma classe. Je contrôle les actions que j'autorise l'extérieur à effectuer sur mon objet list.

Bonjour,

merci déjà pour la précision au sujet de la classe String.

Si j'ai bien compris, lorsqu'une classe demande la valeur d'un objet à travers un getter(), il sera judicieux de fournir une instance provisoire "copie" de l'objet:

Code:

---

1 2 3 4

public Date getDate() { return new Date( this.maDateMembre ); ]

---

Est-ce que ce raisonnement est juste ?

Quant à un setter, il faudrait faire un truc du genre:

Code:

---

1 2 3 4

public void setDate( Date laDatetransmise ) { this.maDateMembre = new ( laDateTransmise ); }

---

Est-ce que ça c'est juste aussi ?

@ bientôt...

Bonjour rtg57,

Citation:

---

[copie dans getter]
[copie dans setter]

Est-ce que ça c'est juste aussi ?

---

Tu as parfaitement raison: c'est ce qu'on appelle la copie défensive. Accessoirement, tu peux aussi faire tes copies avec clone() particulièrement quand tu ne connais pas la classe concrète des objets que tu manipules.

Bien sûr, dans les deux cas (new ou clone), cela implique un surcoût lié à la multiplication d'objets copiés. L'alternative est d'utiliser des objets immutables (comme les string).

http://gfx.developpez.com/tutoriel/java/immuables/

- Sylvain

À noter que bien que tout cela soit vrai en théorie, et doive bel et bien être appliqué dans certains cas quand on se rend compte qu'il y a risque...

Dans le monde réel et la plupart du temps, ben, on s'en cogne. Quand un bout de programme n'est pas censé modifier un objet, on peut généralement s'attendre à ce que le programmeur le sache. C'est pas le genre d'erreur qui va arriver spontanément. Et si, par hasard, les choses, l'interface, la manière de faire ; tout ça font que, en fait, l'erreur ait des chances d'arriver ; alors dans ce cas, oui, il faut savoir faire de la copie défensive.

Comme souvent en informatique, il n'y a pas de "bonne" ou de "mauvaise" réponse. Tout dépend du contexte.

Si tu écris une application, tu peux partir du principe que les objets de cette application ne requièreront sans doute pas de copie défensive: après tout, tu peux dire que c'est toi ou ton équipe qui codez les classes correspondantes et qui les utilisez. Et en résumé, vous savez ce que vous faites.

A l'inverse, si tu écris une bibliothèque - à fortiori une que tu vas distribuer à l'extérieur - j'aurais tout de même tendance à plaider pour la copie défensive. Peut-être pas pour tes classes internes, mais au moins au niveau de tes objets "interfaces" ou de tes "facades". Le premier argument est d'éviter les bugs liés à une mauvaise utilisation. D'accord, comme le souligne thelvin, il faut parfois le chercher. Mais justement, si tu distribues une bibliothèque et que des développeurs se rendent compte qu'avec ce genre de "hack" ils peuvent modifier l'état interne de tes objets pour contourner une limitation ou adapter le comportement de ta bibliothèque à leurs besoins, ils ne vont pas forcément s'en priver :mrgreen:
Et là, implicitement tu rompt l'encapsulation. A partir de ce moment, tu as un problème de couplage fort avec le code client: en effet, si tu modifies ton code, (genre "dans la version 2, on utilise des Calendar au lieu de Date en interne") tu risques de "casser" le code client qui repose sur le fonctionnement interne de tes classe. Selon ta politique, ça peut être le problème du client ("z'ont pas à utiliser des comportements non documentés") ou au contraire ton problème et celui de ton management ("depuis que tu as fais ce changement, l'appli critique de notre plus gros client plante. Va falloir me corriger ça mon gars...").

----

De façon plus terre à terre. Pour palier (partiellement?) à la réduction (minime?) de performances liées à l'utilisation de la copie défensive, la JVM HotSpot server de Java 7 devrait pouvoir éliminer certaines allocations inutiles (http://java.sun.com/javase/7/docs/te...escapeAnalysis). Ca n'est sans doute pas la panacée, mais ça pourrait limiter les scrupules liés à l'utilisation plus systématique de la copie défensive.

----

Maintenant, je répète ce que j'ai dit en préambule: c'est selon ton contexte. L'important, je crois, c'est juste d'être conscient des implications de ce que tu fais.

A+,
- Sylvain

Salut,

Citation:

---

Envoyé par thelvin

Dans le monde réel et la plupart du temps, ben, on s'en cogne.

---

Heu... pas vraiment !

En Java la plupart des classes de bases sont immuables (String, les différents Numbers...) et la copie est implicite sur les type primitif... Mais le problème reste présent si on utilise un type muable comme Date.

Ce n'est pas vraiment un problème de mauvaise utilisation volontaire, mais plutôt de mauvaise utilisation involontaire...

D'ailleurs le fait que la classe Date ne soit pas immuable est une erreur reconnu. C'est un peu pour cela que la plupart de ses méthodes ont été déprécié et que Java 7 devrait inclure une nouvelle API avec des types immuable.


:arrow: Par exemple avec ce code :

Code:

---

1 2 3

Date date = myObject.getDate(); // On récupère la date de l'objet date.setTime( date.getTime() + xxx ); // puis on utilise date pour autre chose

---

1. On récupère la date de l'objet
2. On la modifie (par exemple on ajoute un jour)
3. On utilise la date modifié pour un traitement quelconque, indépendant de notre objet

:arrow: Ce code semble des plus anodin, mais on a quand même modifier la date de notre objet, en outrepassant le getter... :(


Bref : il faut privilégier les types immuables, ou penser à bien protéger ses getter/setter via une copie défensive...

a++

Date est un cas qui me semble un peu particulier, justement parce qu'il devrait être immutable.

Mais en général, il n'y a pas de programmation défensive de ce genre dans la bibliothèque de base Java ni dans la plupart des bibliothèques très connues. Sauf dans les cas où on flaire un risque réel d'erreur. Ça ne pose pas de problème, et vu que c'est plus léger à lire, c'est pratiquement un style de programmation extrêmement repris.

Citation:

---

Envoyé par thelvin

Mais en général, il n'y a pas de programmation défensive de ce genre dans la bibliothèque de base Java ni dans la plupart des bibliothèques très connues.

---

Parce qu'en général on utilise des types immuables avec lesquels la copie défensive est inutile...

Sinon la copie défensive est bien présente, y compris dans l'API de base (par exemple avec les classes Dimension ou Point dans l'API Swing).

:arrow: Dans tous les cas, une absence de copie défensive sur un attribut non-immuable est source d'erreur potentiel. Je ne vois pas en quoi il pourrait y avoir un risque d'erreur moins important dans certains cas...

a++

Comme ce sujet est matière à une intéressante divergence d'opinions, je me suis replongé dans le très bon Effective Java (second edition) (ISBN 0321356683) pour vérifier la position de l'auteur sur ce sujet.

Citation:

---

Envoyé par p184, Item 39: Make defensive copies when needed

You must program defensively with the assumption that clients of your class will do their best to destroy its invariants.

---

Le texte de la première édition est disponible ici: http://www.informit.com/articles/art...31551&seqNum=2

L'auteur argumente sur la création de copies défensives dans les getter/setter (ainsi que pour les paramètres des constructeurs). Par ailleurs, pour une modification, il suggère de faire la copie avant de vérifier la validité des paramètres:

Code:

---

1 2 3 4 5 6 7 8 9 10

public void setSomeDate(Date date) { /* 1) copier */ Date theDate = new Date(date.getTime()); /* 2) vérifier la validité de la copie */ if (isValid(theDate)) { /* 3) remplacer la propriété par la copie */ myDate = theDate; } }

---

La raison d'agir ainsi est d'éviter la fenêtre de vulnérabilité entre la validation de la valeur et la copie, pendant laquelle un autre thread pourrait modifier la donnée.

Enfin, dans le même esprit - et contrairement à ce que je suggérais plus haut - l'auteur déconseille aussi d'utiliser clone() pour faire une copie défensive d'une donnée quand celle-ci n'est pas issue d'une source de confiance: en effet, il fait remarquer à bon escient que le paramètre passé peut être une instance d'une classe dérivée spécialement conçue pour se comporter de manière malicieuse.


Tout ces arguments me semblent convainquant. Et vous, "Dans le monde réel", vous faites comme ça?


- Sylvain

Bonjour a tous,

je suis content que ma question soulève débat ( j'avais peur que ce soit une question niveau "ras des pâquerette" :mrgreen: ).
En tous cas, ce que vous avez écrit m'intéresse fortement.
J'ai fait des essais du genre

Code:

---

1 2	Date maDate1 = ...; Date maDate2 = ...;

---

puis

Code:

---

maDate1 = maDate2;

---

afin de voir quand est-ce qu'il y a copie de référence, ou copie de valeur.
J'ai essayé avec String et d'autres objets...la question qui me vient maintenant: comment sait-on que l'on travaille avec un objet "immuable" ?

Je ne vois rien "d'évident" lorsque je lis la documentation SUN.
Avez-vous une combine là-dessus ?

Merci & @ bientôt...

Citation:

---

Envoyé par rtg57

afin de voir quand est-ce qu'il y a copie de référence, ou copie de valeur.

---

C'est simple : lorsque tu manipules des objets tu auras toujours une copie de la référence, quoi qu'il arrive.
La copie par valeur ne s'applique qu'aux types primitifs.

Citation:

---

Envoyé par rtg57

comment sait-on que l'on travaille avec un objet "immuable" ?

Je ne vois rien "d'évident" lorsque je lis la documentation SUN.
Avez-vous une combine là-dessus ?

---

Malheureusement il n'y a rien de clair et précis.
Le plus simple étant de rechercher le terme "immutable" dans la doc de la classe, pour voir si ils en parlent (mais ce n'est pas forcément le cas :()

Sinon les classes immuables se distinguent par l'absence de setter() et par le mot-clef final qui interdit toute classe fille... mais ce n'est pas les seules conditions !!!


a++

Salut,

j'appuie tout à fait la position d'Adiguba et de sleroux et dans le monde réel je privilégie et conseille fortement l'utilisation d'objets immuables (pour pas dire que je ne fais que ça), n'expose et ne code que le strict nécessaire, fais de la copie défensive lorsque nécessaire et renvoie systématiquement des collections non-modifiables (Collections.unmodifiable*(* *)).

Sinon concernant la question :

Citation:

---

comment sait-on que l'on travaille avec un objet "immuable" ?

---

C'est écrit dans la javadoc. Sinon tu peux regarder si ton objet contient des mutateurs ou non... Dans la majorité des cas ces derniers seront des void (à l'exception des Builders qui se renvoie eux-même)

Citation:

---

Envoyé par rtg57

J'ai fait des essais [...] afin de voir quand est-ce qu'il y a copie de référence, ou copie de valeur.

---

Peut-être que tu viens d'un background C++ où le code suivant effectue une copie de l'objet (éventuellement via son copy constructor). Mais en Java ça n'est jamais le cas:

Code:

---

1 2 3 4

Date maDate1 = maDate2; // en C++, copie de l'objet: maDate1 et maDate2 sont deux objets différents // en Java copie de la référence sur l'objet: maDate1 et maDate2 désignent le même objet

---

Comme l'a dit adiGuba, hormi pour les types primitifs (int, float, etc. <- ceux qui commencent par une minuscule), il n'y a jamais de copie implicite. Tu dois explicitement faire la copie toi-même (new, clone(), en passant par une factory, ...). Le fait qu'un objet soit mutable ou immutable n'altère en rien ce comportement.

Où ça joue, c'est qu'un objet immutable, tu sais que son état ne peut pas changer. Tu peux donc sans scrupule renvoyer une référence sur une propriété immutable, puisque tu es certain que le code client ne pourra pas en altérer le contenu.
De la même manière, si tu reçois en paramètre un objet immutable, tu sais que tu peux l'utiliser sans faire de copie, car son contenu ne pourra pas changer pendant que tu t'en sert.

Citation:

---

Envoyé par adiGuba

Sinon les classes immuables se distinguent par l'absence de setter() et par le mot-clef final

---

Euh, le fait qu'une classe soit finale, ne la rend pas immutable:

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

// // Classe marquée "final" mais l'objet est "mutable" quand même // final class Mutable { private int n;   public void setN(int n) { this.n = n; }   public int getN() { return n; } }   public class C { public static void main(String args[]) { // // La variable est marquée "final" mais ça n'empèche pas de modier // l'état de l'objet "mutable" // final Mutable mutable = new Mutable(); mutable.setN(5); System.out.println(mutable.getN()); mutable.setN(10); System.out.println(mutable.getN()); } }

---

M'est avis que je n'ai pas compris...

;)
- Sylvain

Citation:

---

Envoyé par adiGuba

Euh, le fait qu'une classe soit finale, ne la rend pas immutable

---

Non bien sûr... J'ai indiqué que ce n'était pas les seules conditions ;)

Le problème c'est que si rien n'est indiqué dans la doc, on ne peut pas garantir qu'une classe est immuable sans analyser son code...


a++

Citation:

---

Le problème c'est que si rien n'est indiqué dans la doc, on ne peut pas garantir qu'une classe est immuable sans analyser son code...

---

C'est vrai que c'est particulièrement pénible. J'ai toujours trouvé qu'il manquait à Java un modificateur "const" comme en C++...


Sinon, pour en revenir au modificateur final, j'y ai réfléchi depuis tout à l'heure. L'avantage d'avoir une classe "final", c'est qu'on est certain que l'instance qui est reçue en argument est bien une instance de la classe immutable - et pas d'une classe spécialement conçue pour avoir un comportement malicieux. Je serais peut-être un poil plus clair sur un exemple.

Considérons la classe suivante - dont les instances sont immutables:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

class Immutable { Immutable(int n) { this.n = n; }   public int getN() { return n; }   final private int n; }

---

Et le code d'une classe cliente - tout aussi immutable en apparence:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

class Client { public Client(Immutable immutable) { this.immutable = immutable; }   public int getImmutableValue() { return immutable.getN(); }   final Immutable immutable; }

---

On peut utiliser l'ensemble ainsi:

Code:

---

1 2 3 4 5 6 7 8

final Immutable immutable = new Immutable(5); final Client client = new Client(immutable);   // Affiche 3 fois la même valeur "évidemment": System.out.println(client.getImmutableValue()); System.out.println(client.getImmutableValue()); System.out.println(client.getImmutableValue());

---

Le problème c'est que Client n'est pas aussi immutable que ça! En effet, on peut l'abuser en forgeant une classe dérivé de Immutable ainsi:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

class Fool extends Immutable { public Fool(int n) { super(n); }   public int getN() { return random.nextInt(); }   private Random random = new Random(); }

---

Du coup, on peut casser le fonctionnement de Client juste en passant une instance de Fool au constructeur:

Code:

---

1 2 3 4 5 6 7 8

final Immutable immutable = new Fool(5); final Client client = new Client(immutable);   // Affiche 3 valeurs différentes: System.out.println(client.getImmutableValue()); System.out.println(client.getImmutableValue()); System.out.println(client.getImmutableValue());

---

Effectivement, ce qu'il manque ici, c'est d'ajouter un modificateur "final" à la classe Immutable pour empêcher de fabriquer la classe dérivée Fool. D'un autre côté, on peut se demander si ici on est toujours dans le cas d'une erreur d'utilisation involontaire - ou d'un comportement franchement hostile?
Mais, qu'elles soit volontaire ou non, personnellement j'aurais quand même tendance à croire que ça ne fait que du bien de se prémunir contre ce genre d'erreur...

Comme quoi, c'est une question qui est loin d'être au "ras des pâquerette" :)

- Sylvain

Citation:

---

Envoyé par sleroux

C'est vrai que c'est particulièrement pénible. J'ai toujours trouvé qu'il manquait à Java un modificateur "const" comme en C++...

---

const a quand même un rôle assez différent... dû justement à l'absence de type immuable.



A un moment donné ils y avaient des discussions sur l'ajout d'une annotation @Immutable pour marquer ces classes, le tout couplé avec des vérifications supplémentaires du compilateur... mais ca date et il n'y a rien de neuf de ce coté là !

Citation:

---

Envoyé par sleroux

Sinon, pour en revenir au modificateur final, j'y ai réfléchi depuis tout à l'heure. L'avantage d'avoir une classe "final", c'est qu'on est certain que l'instance qui est reçue en argument est bien une instance de la classe immutable - et pas d'une classe spécialement conçue pour avoir un comportement malicieux.

---

Oui le final permet d'être sûr du type exact de la classe, et donc de son immuabilité. En règle général une classe non-final ne doit pas être considéré comme immuable, justement car une classe fille pourrait "casser" l'immuabilité...

Citation:

---

Envoyé par sleroux

D'un autre côté, on peut se demander si ici on est toujours dans le cas d'une erreur d'utilisation involontaire - ou d'un comportement franchement hostile?

---

Cela peut être malicieux bien sûr... mais cela pourrait également correspondre à un code tout à fait correct et même sans erreur je dirais ! Après tout rien n'interdit de modifier le comportement de la classe parente...



a++

Je vais donner un coup de pieds dans la fourmillière de la copie défensive.

-> ça coute du temps CPU
-> ça coute de la mémoire (on a la copie et l'argument)
-> Il n'est pas toujours possible de faire une copie (les classes complexes n'implémentant pas cloneable ne sont pas légion)
-> Dans la plupart des cas, vous AVEZ besoin que les objets dans votre classe vivent, la copie n'est donc pas souhaitable.

Et les classe java qui référencent d'autres objets sans copie sont légion (Toute l'api collection, toute l'api swing), et certaines exigent pourtant une invariance. Je vais prendre le hashset, si le hash de l'objet change dans le temps, ça fout en l'air le SET, mais le hashset ne fait pas pourtant un clone de l'objet à stocker. En fait, la copie, en générale, n'est pas souhaitable car on veux récupérer exactement la même référence que celle que l'ont a envoyée. Si j'ai une classe "Agenda", j'aimerais quand même que les objet personnes que je met dedans ne soient pas immutable. Et en général (l'exception de l'objet date a déjà été mentionné), les objet java complexes sont destiné à être mutable, donc on en fait pas la copie.

Il faut toujours se poser la question "si l'objet que je stocke se fait tripatouiller, ça a quelles conséquences pour moi?"

Pour moi, j'utilise très peu la copie défensive, on ne s'est que rarement posé la question dans l'équipe, les seules fois où la question se posaient, c'est justement parce que la modification aurait posé problème. Bref, si tu ne ressent pas le besoin de te poser la question, c'est que le problème n'existe pas. Quand tu aura des cas nécessitant une copie, tu t'en rendra compte ;) Mais c'est rare (bien que j'en conviens, ca dépend du logiciel développé)

En l'absence des types immuables, tu aurais bien plus de recourt à la copie défensive ;)

Après c'est sûr qu'il y a deux cas à différencier :

• Les attributs que tu as besoin de contrôler précisément (exemple dans l'API Swing : la position et la taille).
• Les attributs que tu te contente de référencer pour y accéder plus facilement, sans forcément avoir à t'inquiéter de leurs modifications (exemple dans Swing : les composants fils).

Quand aux Set/Map, il est indiqué dans la doc qu'il faut utiliser des types immuables comme clef ;)

a++

Je vous remercie tous pour votre aide.

L'origine de cette question vient du fait que j'ai tendance à utiliser une variable ou un objet, plusieurs fois dans une même méthode. Je m'explique:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

void maMethode() { int variable1;   for( variable1 = ...bla bla )   /.../   variable1 = uneReponseDeFonction();   /.../ }

---

Avec une variable primitive, y a pas de soucis. On peut imaginer maintenant le cas avec un objet:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

void maMethode() { Date maDate;   maDate = maClasse.getDateNaissance(); // Le fameux getter   /.../   maDate = uneReponseDeFonction();   /.../ }

---

* Si maClasse.getDateNaissance() fourni la référence du membre maClasse.dateNaissance...
* Et si uneReponseDeFonction() modifie le contenu de maDate (l'exemple est peut être mal choisi)...
alors je modifie "par mégarde" le contenu du membre maClasse.dateNaissance, qui est pourtant déclaré comme private; et voilà la bourde !!

Je ne cherche pas à protéger le code de mes classes (car je programme pour moi ), je cherche plutôt à faire du code "blindé", à l'épreuve de mes bêtises.

J'ai programmé quelques années en C++, et je n'ai pas encore la philosophie JAVA, c'est pour cela que je fais du code pas très catholique. Il y a peut être une astuce qui permet de se passer de la copie défensive...

@ bientôt...

Citation:

---

Envoyé par rtg57

L'origine de cette question vient du fait que j'ai tendance à utiliser une variable ou un objet, plusieurs fois dans une même méthode. Je m'explique:

Code:

---

1 2 3 4 5 6 7 8

void maMethode() { Date maDate; /.../ maDate = maClasse.getDateNaissance(); // Le fameux getter /.../ maDate = uneReponseDeFonction(); }

---

---

Ici :

• tu déclares une variable maDate de type Date
• puis tu fais pointer cette variable vers l'objet renvoyé par maClasse.getDateNaissance()
• puis tu fais pointer cette variable vers l'objet renvoyé par uneReponseDeFonction(), en "jetant" l'ancienne référence, qui n'est aucunement modifiée par cette action !

Il y pourrait y avoir problème si tu effectuais les actions suivantes:

Code:

---

1 2 3 4 5 6 7 8 9

void maMethode() { Date maDate; /.../ maDate = maClasse.getDateNaissance(); // Le fameux getter /.../ maDate.setDate(0); // appel d'une méthode qui modifie effectivement l'état interne de l'objet (on pourraitt appeler toString sans problème) letsChangeThisDate(maDate); // appel d'une fonction qui agit potentiellement sur les objets passés en paramètres }

---

Citation:

---

Il y pourrait y avoir problème si tu effectuais les actions suivantes:

---

Pas seulement. Dés lors qu'il y a un getter public sur une Date qui est utilisé par différents points de programme, il y a problème potentiel... Exemple en étant simple utilisateur maladroit de la classe:

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

public final class MonObjet {   private static final Date ZERO = getZero();   private final Date birthday;   private MonObjet(Date birthday) { this.birthday = birthday; }   public static MonObjet newInstance(Date birthday) { return new MonObjet(birthday); }   public Date getBirthday() { return birthday; }   public boolean bornBeforeJC() { return ZERO.after(birthday); }   private static Date getZero() { Calendar cal = Calendar.getInstance(); cal.clear(); cal.set(0, 0, 1); return cal.getTime(); } }

---

Et en l'utilisant maladroitement à l'extérieur, je peux entrainer un fonctionnement non désiré:

Code:

---

1 2 3 4 5 6

public static void main(String[] args) { MonObjet monObjet = MonObjet.newInstance(new Date()); System.out.println("Born before JC?"+monObjet.bornBeforeJC()); monObjet.getBirthday().setTime(Long.MIN_VALUE); System.out.println("Born before JC?"+monObjet.bornBeforeJC()); }

---

Ça me retourne:

Citation:

---

Born before JC?false
Born before JC?true

---

Donc dans le cas d'un objet mal fichu comme Date et s'il n'est pas prévu que ta date soit modifiée de l'extérieur, il n' y a que la copie défensive ou la restriction de portée...
As-tu réellement besoin d'exposer ta Date (ou plus généralement ton objet) de manière publique?

Bonjour,

oui j'expose l'objet Date dans la mesure où j'ai une classe qui stocke les données d'individus, dont la date de naissance, et qui doit pourvoir la fournir à d'autres classe de traitement.

Je veux passer par des getter / setter pour maitriser les données stockées, mais je m'aperçois que le getter retourne la référence de l'objet.
Cet objet private dans la classe des données est exposé publiquement à toute classe demandant la valeur de celui-ci à travers le getter.
Dans ce cas précis, je contourne un peu le problème en retournant la valeur sous format long:

Code:

---

return dateNaissance.getTime();

---

. Ceci étant un type primitif, je suis donc assuré que c'est une copie qui est renvoyé.

Dans le cas de String comme pour le patronyme des individus, je fais:

Code:

---

return new String ( patronymeIndividu );

---

. Dans ce cas, je pense que cette précaution est inutile puisque l'on m'a indiqué dans cette discussion que le type String retourne toujours une autre instance de l'objet, et pas l'objet lui-même.

Je constate en tout cas que je dois être très prudent lorsque je récupère une donnée à travers un getter, car finalement, elle n'est pas si protégée que cela.

Merci & @ bientôt...

Oui pour ta String c'est inutile...
Après c'est sans doute une question de gout mais je préfère renvoyer une Date à sa version long, quitte à perdre du temps en en renvoyant une copie.

Citation:

---

Envoyé par rtg57

Dans le cas de String comme pour le patronyme des individus, je fais:

Code:

---

return new String ( patronymeIndividu );

---

. Dans ce cas, je pense que cette précaution est inutile puisque l'on m'a indiqué dans cette discussion que le type String retourne toujours une autre instance de l'objet, et pas l'objet lui-même.

---

Non : c'est inutile car String est un type immuable, qui ne peut donc pas être modifié.

:arrow: Il n'y a donc pas à le protéger. On peut le partager sans problème...

a++

Citation:

---

Envoyé par Heimdal

Pas seulement.

---

L'exemple que tu donnes (monObjet.getBirthday().setTime(Long.MIN_VALUE);) est justement un de ceux que j'ai donné ;)


Dans cette discussion, tout le monde est d'accord pour dire que, lorsqu'une classe A renvoie directement un de ses objets internes (non immutable), il y a un risque pour que le code appelant modifie cet objet, ce qui peut avoir des effets non désirés sur la classe A.
Après, les positions varient entre "il faut coder son API en mode défensif pour empêcher les utilisateurs de faire n'importe quoi" et "si l'utilisateur fait n'importe quoi c'est son problème"...

Cependant, dans le dernier post de rtg57, c'est un autre problème qui est évoqué : visiblement, rtg57 a l'habitude d'utiliser une même variable pour y stocker successivement des objets différents.
J'imagine qu'il tient ça de ses réflexes C/C++, où l'on essaie au maximum de mutualiser les espaces mémoire utilisés... Personnellement, je préfère définir une variable différente pour chaque "donnée" représentée, avec un nom parlant et un scope le plus réduit possible autour du moment où je l'utilise effectivement. Je trouve ça bien plus lisible qu'un code "à la C" avec des variables plus ou moins globales utilisées pour 12 rôles différents et réinitialisées dans 36 boucles et fonctions[*].
En tous cas, même si cette façon de réutiliser les variables n'a pas vraiment lieu d'être en Java, il est certain que l'affectation d'un nouvel objet à une variable ne modifie aucunement l'objet vers lequel pointait précédemment cette variable.

Code:

---

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

Date maDate = new Date(); // je crée un nouvel objet 1 avec un nouvel espace mémoire et je fais pointer maDate vers cet objet   maDate = new Date(); // je crée un nouvel objet 2 avec un nouvel espace mémoire et je fais pointer maDate vers cet objet // la référence à l'objet 1 est perdue, l'espace mémoire 1 sera récupéré plus tard par le garbage collector   maDate = trucmuche.getDate(); // je fais pointer maDate vers trucmuche.date // la référence à l'objet 2 est perdue, l'espace mémoire 2 sera récupéré plus tard par le garbage collector   maDate = new Date(); // je crée un nouvel objet 3 avec un nouvel espace mémoire et je fais pointer maDate vers cet objet // la référence à trucmuche.date existe encore dans trucmuche mais elle n'a plus aucun rapport avec la variable maDate

---

[*] Déjà vu. Déjà refactorisé. Après que je lui ai soumis ma refactorisation, le programmeur à l'origine du code initial m'a alors dit quelque chose dans le style "ouaaaah, c'est plus simple, c'est plus clair, et puis j'en apprends des choses, je ne connaissais pas l'héritage c'est génial ce truc". Ce programmeur codant en Java sans même connaître la notion d'héritage était probablement plus à blâmer que le "style de programmation à la C".

Citation:

---

Envoyé par rtg57

oui j'expose l'objet Date dans la mesure où j'ai une classe qui stocke les données d'individus, dont la date de naissance, et qui doit pourvoir la fournir à d'autres classe de traitement.

---

Si tu veux exposer une propriété de ton objet sans donner la possibilité de modifier sa valeur (read-only), il faut soit renvoyer un type primitif ou un type immutable (qui par nature ne peuvent pas être modifiés), soit renvoyer une copie plus ou moins profonde de la propriété (la copie sera éventuellement modifiée mais cela n'affectera pas ton objet).
Si tu veux laisser la responsabilité au code appelant de modifier ou non ta propriété, tu peux renvoyer directement l'objet en question.
Si tu veux permettre au code appelant de modifier la propriété, mais pas n'importe comment, il faut encapsuler les méthodes permettant de modifier la propriété dans des méthodes ne présentant à l'extérieur que le type d'action que tu veux permettre.


Exemple à la con : un compteur qui utilise un entier "mutable".
Méthode 1 : je laisse le code appelant faire ce qu'il veut via un getter et un setter, il est alors de sa responsabilité de ne pas faire n'importe quoi avec mon compteur, comme par exemple y mettre un nombre négatif, ou ajouter 2 d'un coup, ou modifier "par erreur" le WrappedInteger renvoyé par le getter...
Méthode 2 : j'estime que le fonctionnement de mon compteur doit être bridé, je m'arrange donc pour renvoyer une copie de mon WrappedInteger via le getter, et j'encapsule les méthodes permettant de modifier sa valeur plutôt que de présenter directement un setter.

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

class WrappedInteger { private int value; public WrappedInteger(int value) { this.value = value; } public int getValue() { return this.value; } public void setValue(int value) { this.value = value; } public WrappedInteger clone() { return new WrappedInteger(this.value); } }   class Compteur1 { private WrappedInteger value; public Compteur1() { value = new WrappedInteger(0); } public WrappedInteger getValue() { return value; } public void setValue(WrappedInteger val) { value = val; } }   class Compteur2 { private WrappedInteger value; public Compteur2() { value = new WrappedInteger(0); } public WrappedInteger getValue() { return value.clone(); } public void reset() { value.setValue(0); } public void increment() { value.setValue(value.getValue()+1); } }

---

Merci à tous pour ces explications détaillées,

je vais m'mprimer cette discussion et méditer dessus :mrgreen:

@ bientôt...