Pourquoi les classes wrapper pour les primitifs n'ont-elles pas de setter?

Question

Quelle est la raison pour laquelle les classes Wrapper (comme Integer, Double, etc.) n'ont pas de setter pour leur valeur primitive interne ?

Je pose cette question parce que ce genre de fonctionnalité aurait simplifié les calculs, et aurait rendu le langage Java un peu plus flexible.

Laissez-moi vous donner quelques exemples.

1) Prenons l'exemple suivant :

Integer x = new Integer(5);
x++;

Le code précédent, en coulisses, effectue une autoboxing. Quelque chose comme :

int x_tmp = x.intValue();
x_tmp++;
x = new Integer(x_tmp); // Oui, c'est une nouvelle allocation mémoire

En raison de ce problème, effectuer des calculs sur un Wrapper est plus lent que sur des types primitifs simples. Avec un setter, il aurait été plus facile d'augmenter la valeur interne, sans allouer un autre objet dans le tas.

2) Un autre problème qui me dérange est qu'il est impossible en Java d'écrire une fonction d'échange comme je peux le faire en C (en utilisant des pointeurs) ou en C++ (pointeurs ou références).

Si j'écris void swap(Integer x, Integer y) je ne peux pas accéder à la valeur interne et il me sera impossible de permuter les valeurs.

PS : Un ami m'a suggéré de considérer le point de vue plus large, et de penser en termes de concurrence et d'immutabilité des types.

Alors avez-vous une explication à cela ? Merci !

Answer 1

Les classes d'enveloppe ne sont généralement pas utilisées sauf si vous avez besoin de les mettre dans une collection. S'ils étaient mutables, cela poserait des problèmes s'ils étaient utilisés à l'intérieur d'ensembles et en tant que clés pour des tables de hachage.

Les ensembles et les tables de hachage ont besoin que la valeur de hachage soit toujours la même.

Answer 2

1) Avec un setter, les types enveloppe seraient mutables. L'immuabilité est une bonne chose à bien des égards... le multithreading, la compréhension générale du code, etc. Personnellement, je trouve dommage que Calendar et Date soient mutables, par exemple.

En fait, votre expansion de x++; n'est pas tout à fait correcte - elle utilise Integer.valueOf qui ne crée pas toujours une nouvelle valeur. Par exemple :

Integer x = 5;
x++;
Integer y = 5;
y++;

// Cela imprime true    
System.out.println(x == y); // Comparer les références

Seule une plage limitée de valeurs Integer sont mises en cache de cette manière (la spécification définit quelles valeurs doivent se comporter de cette manière, mais permet une plage plus large si la machine virtuelle Java le souhaite)... mais cela signifie qu'un nouvel objet ne sera pas toujours créé.

2) Oui, Java n'a pas le passage par référence. Honnêtement, je trouve très rarement que cela pose problème. À quelle fréquence avez-vous vraiment besoin d'échanger les valeurs des variables ?

Answer 3

Mettre en cache les entiers dans la plage de -128 à 127 nécessite des Entiers immuables. Considérez le code suivant :

Integer id = Integer.valueOf(1);  // un nouvel Entier, mis en cache dans la classe Integer

// et ailleurs

Integer key = Integer.valueOf(1);  // retourne la valeur mise en cache

Maintenant, si Integer était mutable et avait un setter et que quelqu'un faisait :

key.setValue(2);  // code Java non valide, juste pour la démonstration

cela changerait également la valeur de id et, à la surprise de beaucoup de gens :

Integer one = Integer.valueOf(1);
if (one != 1)
   System.out.println("Surprise! Je sais, vous vous attendiez à `1`, mais ...");

Answer 4

En Java, les chaînes de caractères et les classes wrapper sont conçues comme immuables pour éviter des modifications accidentelles des données. Vous pouvez consulter l'article ci-dessous pour plus d'informations.

Pourquoi les chaînes de caractères et les classes wrapper sont-elles immuables en Java ?