Bonjour :)
par exemple encapsuler un "R" dans du String ?
ou un int dans du Integer ?
;)
Version imprimable
Bonjour :)
par exemple encapsuler un "R" dans du String ?
ou un int dans du Integer ?
;)
Bonjour,
Oui c'est utile car ça permet d'utiliser des classes/méthodes qui manipulent des objets et pas de types primitifs, par exemple les collections comme java.util.List:
Ça permet aussi de représenter l'absence de valeur avec null si on ne veut pas utiliser une valeur primitive par défaut, par exemple:Code:
1
2 List<Integer> list = new ArrayList<Integer>(); list.add(Integer.valueOf(10));
Au passage, il existe la classe Character pour "wrapper" un charCode:
1
2 Integer integer = null; int i = null; // ne compile pas
En Java je dirai non car ce n'est pas du "pur objet". Et si c'était le cas il n'y aurait plus de distinction entre les deux je pense.
Mais le int, par exemple, sert pour accéder aux index d'un tableau, donc je ne vois pas l'intérêt de manipuler les Integer à tout bout de code.
Il y avait justement un article du dev mag là-dessus:Citation:
Je prolongerais alors la question : doit-on en arriver à bannir les types primitifs au profit du tout objet ?
ftp://ftp-developpez.com/magazine/DevMag201010.pdf
Page 2, colonne de droite en haut
Citation:
Il pourrait être intéressant de passer au tout-objet et de se
débarrasser de cela.
Les types primitifs pourraient être remplacés par le type
wrapper correspondant (quitte à ce que la JVM continue à
les utiliser en interne pour des raisons de performance si
besoin)...
Une telle évolution nécessiterait bien sûr l'adaptation des casts ; ça serait loin d'être absurde, en tout cas.
Attention qu'un objet consomme plus de mémoire qu'un type de base, on aura toujours besoin des types de base pour les opérations de base. Par exemple, un byte[5000000] consommera 4 à 8 fois de mémoire qu'un Byte[5000000] (8 bits vs un référence supposé occuper 32 ou 64 bits suivant la jvm).
Si l'on veux abolir la frontière, il faudrait presque faire l'inverse, tout travailler en int/byt (du moins en interne) et ne jamais instancier les Object (c'est à dire donner automatiquement au vol la nature objet à la valeur sans allocation particulière) mais là on passer à un sacré remaniement de la JVM :aie:
Non.
L'article que cite provirus est intéressant mais il se place dans le cas d'un hypothétique nouveau langage Java incompatible avec l'ancien.
Java n'a pas été conçu pour gérer le tout objet et ce n'est plus faisable sans tout casser.
l'auto-(un)boxing de Java n'est qu'une rustine ajoutée à l'origine pour utiliser simplement les types primitifs dans les collections génériques. Mais il est très insuffisant pour permettre de remplacer systématiquement les primitifs par des objets.
Utiliser les objets lorsque ce n'est pas nécessaire :
- plombe les performances inutilement
- alourdit le code si on les utilise correctement (en tant qu'obets)
- conduit à des erreurs bêtes si on les utilise naïvement (comme des primtifs)