L'apparition du mot-clé const est-il prévu dans une version à venir du JDK?

class Personne implements ConstPersonne

semble une bonne idée, mais le problème c'est que c'est cassable.

Code:

---

1 2 3 4 5 6 7 8

public void essai() { ConstPersonne cp = new Personne("Martin");   Personne p = (Personne)cp; // Cela ne fera pas de ClassCastException puisque cp est de classe Personne! p.setNom("Dupont"); }

---

La solution est de faire quelque-chose (de tête) comme ceci:

Code:

---

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

/** Une personne. */ class Personne { /** Le nom de la personne. */ private String m_szNom;   /** Construire une personne qui a un nom. */ public Personne(String szNom) {setNom(szNom);}   public interface ConstPersonne { /** Renvoyer le nom de la personne. */ public String getNom() {return(m_szNom);} }   /** Fixer le nom de la personne. */ public void setNom(String szNom) {m_szNom = szNom;}; }

---

Il faut adapter un peu ce code, mais l'idée est là. on peut obtenir alors une classe de type ConstPersonne, qui n'est plus castable en Personne, ce qui était problématique. Le prix, c'est que tout ce dont pouvait hériter Personne, on en perd la notion dans l'interface interne.

Ca reste quand-même lourd, en terme de préparation, que l'on doive construire une interface immutable ou une classe immutable (qui travaille par copie).
const simplifierait diablement l'ensemble.

@grunt2000 :

Je pense qu'il n'y a pas de solution en java ; il FAUT plusieurs classes, et c'est une fausse piste que de vouloir n'en faire qu'une pour traiter ce genre de problème.

C'est ce que je fais de plus en plus pour ma part, après avoir retourné le problème dans tous les sens, et finalement c'est ce qui fonctionne le mieux.

Il y a plein de niveaux intérmédaires, dont certains sont viables (par exemple le get sont public, tandis que les set sont package private ou protected, ce qui forme l'apparence d'une classe immuable), mais la morale de tout ça est qu'il faut deux classes, et que c'est le mieux, pour résoudre vraiment les problèmes de muabilité / immuabilité.

Citation:

---

Envoyé par grunt2000

class Personne implements ConstPersonne

semble une bonne idée, mais le problème c'est que c'est cassable.

---

Le const du C++ aussi est cassable via l'opérateur const_cast il me semble...

De toute manière l'utilisation d'un cast ne peut pas être considéré comme un oubli ou une erreur involontaire...


Enfin si tu veux vraiment empêcher les modifs via un cast il suffit d'utiliser une classe Wrapper :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public final class ConstPersonneWrapper implements ConstPersonne { private final ConstPersonne instance;   public ConstPersonneWrapper(ConstPersonne instance) { this.instance = instance; }   public String getNom() { return instance.getNom(); } }

---

Et à la rigeur tu pourrais utiliser un Proxy pour les générer dynamiquement :

Code:

---

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

@SuppressWarnings("unchecked") public static <T> T wrapper (Class<T> interfaceType, final T instance) { return (T) Proxy.newProxyInstance( instance.getClass().getClassLoader(), new Class<?>[]{interfaceType}, new InvocationHandler() { public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { // On redirige la méthode vers l'instance return method.invoke(instance, args); } }); }

---

Que tu utilises comme cela :

Code:

---

1 2	Personne personne = new Personne(); ConstPersonne constPersonne = wrapper(ConstPersonne.class, personne);

---

Et là l'instance constPersonne n'est plus castable en Personne... mais cela implique la création d'un nouvel objet...

Citation:

---

Envoyé par grunt2000

Ca reste quand-même lourd, en terme de préparation, que l'on doive construire une interface immutable ou une classe immutable (qui travaille par copie).

---

Les classes immuables utilisent des copie seulement lorsqu'elles contiennent des objets muables, mais sinon le concept de l'immuabilité évite justement un grand nombre de copie inutile, qui en C++ sont remplacé manuellement par des références constante (const Type &).


Si l'utilisation de const peut avoir un intérêt, il ne doit pas remplacer le concept de l'immuabilité (or on dirait que c'est ce que tu veux faire).

L'immuabilité est un des concepts de base de Java. Si la classe String n'était pas immuable mais utilisait des const, tu devrais faire un code du genre :

Code:

---

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

public class Personne {   private String nom;   public Personne(String nom) { this.nom = nom.clone(); }   public void setNom(String nom) { this.nom = nom.clone(); }   public const String getNom() const { return this.nom; } }

---

Bref tout ce qu'on gagnerait ce serait des copies d'objets en plus (et plus de possibilité d'erreur de se tromper).


Le const est plus adapté au C++ (passage par copie par défaut, appel du constructeur par copie implicitement, ...)


a++

Si l'utilisation de const peut avoir un intérêt, il ne doit pas remplacer le concept de l'immuabilité (or on dirait que c'est ce que tu veux faire).
C'est tout à fait ce que je veux faire. En C++, je n'ai jamais vu l'emploi d'une classe Immutable, rendu à 95% inutile grâce à const.

L'immuabilité est un des concepts de base de Java. Si la classe String n'était pas immuable mais utilisait des const, tu devrais faire un code du genre : <suit le code>
L'immutabilité est le palliatif de Java à son l'absence de "const-correctness". Et je me répète, mais les classes Immutables n'apportent pas la garantie de n'être pas modifiables.

Si je reçoit un fichier TotoImmutable.class à intégrer dans mon jar, je me dis quoi? Que c'est une classe immutable ou non? D'après son nom, oui. Mais dans les faits? Il est là, le problème.

L'exemple que tu donnes avec String est un peu biaisé car cette classe se comporte comme un type primitif.
Et si je t'accorde que c'est une chose utile et agréable qu'il le soit, il faut considérer une classe ayant des membres d'un type autre que String et types primitifs pour étudier la constance/immuabilité.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

public class Personne { /** Date de naissance. */ Calendar m_dtNaissance; /** Nom. */ String m_szNom; /** Collection de prénoms de la personne. */ Prenoms m_prenoms; /** Un setter d'objet immutable pour les prénoms. */ public void setPrenoms(Prenoms prenoms) { m_prenoms = prenoms.clone(); // Ne suffirait pas. Les éléments des postes resteraient les mêmes. m_prenoms = new Prenoms(); for (Prenom p : prenoms) m_prenoms.ajouter(p.clone()); } }

---

Il suffit vraiment de pas grand-chose pour se tromper régulièrement.

Citation:

---

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:

Code:

---

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:

Code:

---

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:

Code:

---

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" :

Code:

---

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...

Citation:

---

Envoyé par grunt2000

C'est tout à fait ce que je veux faire. En C++, je n'ai jamais vu l'emploi d'une classe Immutable, rendu à 95% inutile grâce à const.

---

Pour moi c'est le const qui est obsolète grâce aux classes immuables ;)

En fait c'est surtout une différence de philosophie entre C++ et Java...
Bien que ce soit deux langages objets avec une syntaxe relativement proche, ils n'ont pas grand chose en commum...

Citation:

---

Envoyé par grunt2000

L'immutabilité est le palliatif de Java à son l'absence de "const-correctness".

---

L'immuabilité est l'alternative choisit par Java pour éviter la multiplication des copies implicites du C++... Elle adopte un choix différent du "const-correctness"...

Citation:

---

Envoyé par grunt2000

Et je me répète, mais les classes Immutables n'apportent pas la garantie de n'être pas modifiables.

---

Prouve le alors !

Si on excepte une erreur de programmation, le seul moyen de passer outre l'immuabiltié est d'utiliser la reflection (et encore cela peut être bloqué par un SecurityManager).

Quand à la garantie du const elle est aussi cassé par le const_cast non ? (tu n'as pas répondu et je n'en suis pas sûr)

Citation:

---

Envoyé par grunt2000

L'exemple que tu donnes avec String est un peu biaisé car cette classe se comporte comme un type primitif.

---

String est une classe immuable...


Et je n'ai pas trop compris ton exemple avec la collections de prénoms...





Enfin en ce qui concerne le principe de la vue non-modifiable, la solution de l'interface est toujours d'actualité :

Code:

---

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

public interface ConstPersonne { public String getNom(); }   public class Personne implements ConstPersonne { private String nom;   public String getNom() { return nom; }   public void setNom(String nom) { this.nom = nom; }   public ConstPersonne nonModifiableView() { return this; } }

---

E si tu veux vraiment empêcher les cast il suffit d'utiliser une classe wrapper :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public final class ConstPersonneWrapper implements ConstPersonne { private final ConstPersonne instance;   public ConstPersonneWrapper(ConstPersonne instance) { this.instance = instance; }   public String getNom() { return instance.getNom(); } }

---

Que tu utilises comme cela :

Code:

---

1 2 3

public ConstPersonne nonModifiableView() { return new ConstPersonneWrapper(this); }

---

Et à la rigueur tu peux utiliser un proxy pour générer dynamiquement le wrapper vers l'interface :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

@SuppressWarnings("unchecked") // warning inutile car le cast ne produit pas d'erreur public static <T> T wrapper (Class<T> interfaceType, final T instance) { return (T) Proxy.newProxyInstance( instance.getClass().getClassLoader(), new Class<?>[]{interfaceType}, new InvocationHandler() { public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { return method.invoke(instance, args); } }); }

---

Que tu utilises comme cela :

Code:

---

1 2 3

public ConstPersonne nonModifiableView() { return wrapper(ConstPersonne.class, this); }

---

Enfin pour finir : bien sûr que le const pourrait être une solution à ce problème, mais son intégration apporterait trop de problème de compatibilité pour qu'il soit réellement utiliser massivement... ce qui lui ferait perdre tout son intérêt...


a++

Citation:

---

Envoyé par adiGuba

Enfin en ce qui concerne le principe de la vue non-modifiable, la solution de l'interface est toujours d'actualité :

---

Oui, mais je ne trouve pas ça très habile à l'usage. Il me semble que pour les immuables le mieux reste la classe pure et dure, final, etc.

Les avantages :

• hashcode et equals peuvent être mieux gérés
• donc usage fiable dans les maps
• topo similaire au niveau des classements
• sûreté au niveau des accés concurrents des threads (forcément ! )
• plus grande facilité de transfert entre muable et immuable

Inconvénients :

• aucun :D

Citation:

---

Envoyé par gifffftane

Oui, mais je ne trouve pas ça très habile à l'usage. Il me semble que pour les immuables le mieux reste la classe pure et dure, final, etc.

---

Je suis d'accord avec toi sur les avantages des classes immuables ;)

Mais la "vue non-modifiable" n'a pas pour objectif de "concurrencer" l'immuabilité... cela apporte une solution à un autre problème (une vue en "read-only" sur un objet mutable).

a++

Citation:

---

Envoyé par adiGuba

Mais la "vue non-modifiable" n'a pas pour objectif de "concurrencer" l'immuabilité... cela apporte une solution à un autre problème (une vue en "read-only" sur un objet mutable).

a++

---

Pour cet usage, je préfère passer par la méthode clone, que je trouve injustement délaissée par les programmeurs.

Il me semble que cela résoud le problème de protéger une valeur interne, en laissant ouvert à l'extérieur toutes les fonctions et les valeurs d'une classe. Donc c'est mieux :king: Et là, aucun besoin d'écrire des interfaces de plus.

Bien sûr, il faut régler la profondeur du clone... mais cela me parait une démarche assez naturelle et assez claire... du moins s'il n'y avait pas tous ces préjugés sur cette méthode.

Citation:

---

Envoyé par gifffftane

Pour cet usage, je préfère passer par la méthode clone, que je trouve injustement délaissée par les programmeurs.

---

Ce n'est pas la même chose puisque dans ce cas tu as deux objets distincts ;)

La "vue non-modifiable" permet de voir les modifications qui sont faite sur la classe originale, tout en lui interdisant de la modifier.

Bref la vue non-modifiable permet d'interdire d'utiliser un setter...

a++

Zéro inconvénients. Allons!

Inconvénients:
- si c'est une classe immutable qui est réalisée, travaillant en interne sur une copie de données.

• Il y a consommation de temps système, de ressources mémoire.
  
• Il faut créer un code dédié pour les setters ou mettre en place une solide méthode clone(). Il existe donc deux implémentations d'une classe. La classe A et la classe AImmutable. Le projet grandit, porteurs d'objets - pardon - encombrants.
  
• Le nombre de bugs possibles lors de l'écriture d'un clone est important. Il est vraiment très facile de se tromper. Et quand on s'est trompé, sa classe immutable ne vaut plus rien.

- Si l'immuabilité est réalisée par une interface reprenant les getters et non une classe dédiée alors:

• 20% (au moins) des développeurs se trompent et écrivent:
  class Personne extends ConstPersonne, ce qui est une faute.
  
• Si l'on fait une interface interne, qui protège effectivement l'objet, c'est lourd à implémenter.
  
• Dans ce cas de figure, le comportement se rapproche du const avec sa "faiblesse":
  Si AImmutable pointe sur A et que A évolue, AImmutable le verra. Dans le cas d'une classe Immutable pure copie (plus haut) AImmutable ne le verrait pas.

Citation:

---

Envoyé par adiGuba

Ce n'est pas la même chose puisque dans ce cas tu as deux objets distincts ;)

---

Je le sais bien que ce n'est pas la même chose. Je considère que ce que je propose est mieux ; je n'aime pas beaucoup, je l'admets, le concept de vue non modifiable, qui me parait une mauvaise solution, du moins avec ce que l'on dispose en java.

Citation:

---

Envoyé par adiGuba

La "vue non-modifiable" permet de voir les modifications qui sont faite sur la classe originale, tout en lui interdisant de la modifier.

Bref la vue non-modifiable permet d'interdire d'utiliser un setter...

a++

---

Je vais être provocateur : et alors ?? à quoi cela sert-il ?

Moi aussi j'ai inventé quantité d'interfaces etc pour protéger des valeurs... j'étais souvent peu satisfait du résultat, qui me coutait beaucoup de temps et que n'importe quel stagiaire débutant pouvait contourner facilement de toutes façons.

Il me semble qu'il vaut mieux traiter les choses en correspondance avec le domaine que l'on exprime, et que les protections s'établissent quasiment d'elles mêmes.

S'il apparaît des risques d'interventions intenpestives, alors il vaut mieux résoudre les choses par le biais de l'état de l'objet, ou de la connaissance de son contexte, bref par la robustesse. Finalement, faire des objets très ouverts, capables de répondre à tout, mais pas n'importe comment ; toujours de façon adéquate. C'est là que se trouve la véritable protection.

Cette approche me semble beaucoup plus efficace que le concept de vue non modifiable, casse gueule en java. En d'autres langages, peut être, en java, bof bof.

Et puis au fait tant qu'on y est, une autre technique utile et mieux que l'idée de la vue non modifiable est celle du listener (entre écouter et voir, y a-t-il une différence ? ), qui demande à réfléchir sur qui écoute quoi.

Citation:

---

Envoyé par grunt2000

Zéro inconvénients. Allons!

Inconvénients:
- si c'est une classe immutable qui est réalisée, travaillant en interne sur une copie de données.

• Il y a consommation de temps système, de ressources mémoire.
  

---

• Au niveau de la consomation des ressources, il faut toujours comparer deux solutions, donc deux consomations. Evidemment qu'une solution consome des ressources, mais ce n'est pas un défaut en soi.
  
  Ici au niveau de la solution classe / classe immuable : deux classes. C'est pas mal non ? Il y a mieux en java ??
  
  
  
  Citation:

  ---

  Envoyé par grunt2000
• Il faut créer un code dédié pour les setters ou mettre en place une solide méthode clone(). Il existe donc deux implémentations d'une classe. La classe A et la classe AImmutable. Le projet grandit, porteurs d'objets - pardon - encombrants.