Envoyé par
grunt2000
Oui, absolument!
Personne p1 = new Personne();
const Personne p2 = new Personne();
à partir du moment où il existe une variable autonome p1 qui se balade, et que p2 fait une simple référence à p1, si p1 est modifié, p2 le sera aussi.
Il n'y a pas de magie dans ce cas-là: aucun moyen de l'éviter...
En revanche, en manipulant p2 tu ne pourras rien modifier.
C'est comme si je te donne un accès en lecture à mon compte en banque. Tu ne peux pas verser ou retirer de l'argent dessus.
Mais si moi, dans le même temps, je conserve une autre référence dessus - elle modifiable - et que j'y mets ou que j'en retire de l'argent, eh bien nécessairement, tu verras les sommes évoluer dessus... alors que tu as un pointeur const!
Mais l'important pour moi, c'aura été qu'en te donnant un accès const à mon compte en banque je serai sûr que toi tu ne pourras pas le modifier!
const, ce n'est pas forcément la garantie qu'un objet garde la même valeur (ce serait trop complexe à vérifier), c'est garantir que l'on ne peut pas, soi, le modifier dans un certain périmètre.
OK alors ça n'a plus rien à voir avec le design pattern immutable.
Cela correspond à "vue non modifiable", comme le pattern utilisé dans la classe Collections (Collections.unmodifiableCollection(...)), qui envoie une exception au runtime.
Autant je disais que c'était inintéressant d'utiliser const pour faire de l'immutable (car non faisable), autant pour faire une "vue non modifiable" cela serait d'après moi une avancée
(rien que pour la méthode "unmodifiableCollection" qui ne jète une erreur qu'au runtime).
Et je suis d'accord avec toi, ça arrive souvent qu'on veuille à partir d'un get renvoyer une référence sur un objet non modifiable en lecture, sans avoir à rediriger toutes les méthodes qui ne modifient pas l'état de l'objet.
Donc une solution avec l'affectation dans un seul sens:
UnObjet nonModifiable = (const UnObjet) unObjet;
Avec la déclaration des méthodes "qui ne modifient pas l'objet", il faut utiliser un autre mot-clé que const:
public const const UnObjet get() {...} //une méthode constante qui renvoie un objet constant
Ceci n'est pas très lisible. Et il y a pire:
public const UnObjet get() {...} // c'est la méthode qui est constante ou l'objet renvoyé?
On pourrait réutiliser la syntaxe JML avec le mot-clé "pure" :
public pure int get() {...} // ne modifie pas l'objet
Et donc les variables déclarées const ne pourraient accéder qu'aux méthodes pures de l'objet référencé.
Je suis quasiment totalement pour.
Le seul problème c'est la compatibilité ascendante:
- si une api rajoute dans le retour d'une méthode le mot-clé const pour indiquer qu'un objet est constant, toutes les classes qui appellent cette méthode et qui référencent l'objet dans une variable UnObjet au lieu de const UnObjet ne compileront plus...
Partager