Quand utiliser la classe wrapper et le type primitif
Quand devrais-je aller pour une classe wrapper sur des types primitifs? Ou dans quelles circonstances dois-je choisir entre les types wrapper/primitif?
D'autres ont mentionné que certaines constructions telles que Collections nécessitent des objets et que ceux-ci ont plus de temps système que leurs homologues primitifs (mémoire et boxing).
Une autre considération est:
Il peut être pratique d’initialiser Objects avec null ou d’envoyer des paramètres null dans une méthode/un constructeur pour indiquer l’état ou la fonction. Cela ne peut pas être fait avec des primitives.
De nombreux programmeurs initialisent les nombres à 0 (valeur par défaut) ou -1 pour signifier cela, mais selon le scénario, cela peut être incorrect ou trompeur.
Cela préparera également la scène pour une NullPointerException lorsque quelque chose est utilisé de manière incorrecte, ce qui est beaucoup plus convivial pour les programmeurs que certains bogues arbitraires sur toute la ligne.
En règle générale, vous devez utiliser des types primitifs, sauf si vous besoin un objet pour une raison quelconque (par exemple, pour placer une collection). Même dans ce cas, envisagez une approche différente qui ne nécessite pas d'objet si vous souhaitez optimiser les performances numériques. Ceci est conseillé par la documentation , et cet article montre comment la boxe automatique peut entraîner une grande différence de performances.
À mon avis, si mes membres de classe sont des variables d'encapsulation, les valeurs par défaut ne sont pas utilisées, ce qui est un comportement favorable au développeur.
1.
class Person {
int SSN ; // gets initialized to zero by default
}
2.
class PersonBetter {
Integer SSN; //gets initialized to null by default
}
Dans le premier cas, vous ne pouvez pas conserver la valeur SSN non initialisée. Cela peut faire mal si vous ne vérifiez pas si la valeur a été définie avant de tenter de l'utiliser.
Dans le second cas, vous pouvez garder le SSN initialisé avec null. Cela peut conduire à NullPointerException mais il vaut mieux insérer sans le savoir des valeurs par défaut (zéro) en tant que SSN dans la base de données chaque fois que vous essayez de l'utiliser sans initialiser le champ SSN.
Je voudrais seulement utiliser les types de wrapper si vous devez.
En les utilisant, vous ne gagnez pas grand chose, mis à part le fait qu’ils sont Objects.
De plus, vous perdez du temps système en termes d’utilisation de la mémoire et de temps passé en boxe/déballage.
Les collections sont le cas typique des simples objets wrapper Java. Cependant, vous pouvez envisager de donner au wrapper une signification plus spécifique dans le code (objet value).
À mon humble avis, il est presque toujours avantageux d'utiliser des objets de valeur lorsqu'il s'agit de lisibilité et de maintenance du code. Envelopper des structures de données simples à l'intérieur d'objets quand ils ont certaines responsabilités simplifie souvent le code. C’est quelque chose de très important dans Conception par domaine .
Il y a bien sûr le problème de performance, mais j'ai tendance à l'ignorer jusqu'à ce que j'ai la possibilité de mesurer la performance avec des données appropriées et de faire des actions plus dirigées vers le domaine problématique. Il peut également être plus facile de comprendre le problème de performances si le code est également facile à comprendre.
Pratiquement, j'avais rencontré une situation où l'utilisation de la classe wrapper pouvait être expliquée.
J'ai créé une classe de service qui avait une variable de type long
- Si la variable est de type
long- lorsqu'elle n'est pas initialisée, elle sera définie sur 0 - cela déroutera l'utilisateur lorsqu'il sera affiché dans l'interface graphique - Si la variable est de type
Long- lorsqu'elle n'est pas initialisée, elle sera définie surnull- cette valeur null ne s'affichera pas dans l'interface graphique.
Ceci s'applique également à Boolean où les valeurs peuvent être plus déroutantes lorsque nous utilisons primitive boolean (la valeur par défaut est false).
les performances d'applications dominées par les calculs numériques peuvent grandement bénéficier de l'utilisation de primitives.
types primitifs, on utilise l'opérateur ==, mais pour wrapper, le choix préféré est d'appeler la méthode equals ().
"Types primitifs considérés comme nuisibles" car ils mélangent "sémantique procédurale dans un modèle par ailleurs uniforme orienté objet.
De nombreux programmeurs initialisent les nombres à 0 (valeur par défaut) ou -1 pour signifier cela, mais selon le scénario, cela peut être incorrect ou trompeur.
Si vous voulez utiliser Collections, vous devez utilisez les classes Wrapper.
Les types primitifs sont utilisés pour les tableaux. De même, pour représenter des données qui n'ont aucun comportement, par exemple un compteur ou une condition booléenne.
Depuis l'autoboxing, la frontière "quand utiliser primitive ou wrapper" est devenue assez floue.
Mais rappelez-vous, les wrappers sont des objets, vous obtenez donc toutes les fonctionnalités java sophistiquées. Par exemple, vous pouvez utiliser la réflexion pour créer des objets Integer, mais pas des valeurs int. Les classes wrapper ont également des méthodes telles que valueOf.
Si vous voulez créer un type de valeur. Quelque chose comme un ProductSKU ou AirportCode.
Lorsqu'un type primitif (chaîne dans mes exemples) définit l'égalité, vous souhaiterez le remplacer.
Les valeurs primitives en Java ne sont pas des objets. Afin de manipuler ces valeurs en tant qu'objet, le package Java.lang fournit une classe wrapper pour chaque type de données primitif.
Toutes les classes Wrapper sont finales. L'objet de toutes les classes wrapper pouvant être instanciées est immuable, ce qui signifie que la valeur de l'objet wrapper ne peut pas être modifiée.
Bien que la classe void soit considérée comme une classe wrapper, elle n’enveloppe aucune valeur primitive et n’est pas insatiable. Il n'a pas de constructeur public, il dénote simplement un objet de classe représentant le mot clé void.