Réponses:
D'autres ont mentionné que certaines constructions telles que Collectionsnécessitent des objets et que les objets ont plus de surcharge que leurs homologues primitifs (mémoire et boxe).
Une autre considération est:
Il peut être pratique d'initialiser des objets nullou d'envoyer des nullparamètres 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 (par défaut) ou -1 pour signifier cela, mais selon le scénario, cela peut être incorrect ou trompeur.
Cela mettra également en scène un NullPointerExceptionmoment où quelque chose est mal utilisé, ce qui est beaucoup plus convivial pour les programmeurs que certains bogues arbitraires sur toute la ligne.
En général, vous devriez utiliser des types primitifs à moins que vous n'ayez besoin d' un objet pour une raison quelconque (par exemple pour mettre dans une collection). Même dans ce cas, envisagez une approche différente qui ne nécessite pas d'objet si vous souhaitez maximiser les performances numériques. Cela est conseillé par la documentation et cet article montre comment l'auto-boxing peut provoquer une grande différence de performances.
Integerest plus lisible que int.
À mon avis, si les membres de ma classe sont des variables wrapper, cela ne dépend pas des valeurs par défaut, ce qui est un comportement convivial pour les développeurs.
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 être douloureux si vous ne vérifiez pas si la valeur a été définie avant d'essayer de l'utiliser.
Dans le second cas, vous pouvez garder le SSN initialisé avec null. Ce qui peut conduire à NullPointerException, mais c'est mieux que d'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.
PersonBuilderqui lève une exception si le SSN n'est pas défini avant d'appeler "build" pour obtenir l' Personinstance. Je pense que ce genre de chose est excessif, mais c'est ce que le langage Java promeut pour des modèles appropriés.
Je n'utiliserais les types de wrapper que si vous le devez.
En les utilisant, vous ne gagnez pas grand-chose, à part le fait qu'ils le sont Objects.
Et, vous perdez des frais généraux dans l'utilisation de la mémoire et le temps passé à boxer / déballer.
Pratiquement j'avais rencontré une situation où l'utilisation de la classe wrapper peut être expliquée.
J'ai créé une classe de service qui avait une longvariable de type
long- lorsqu'elle n'est pas initialisée, elle sera définie sur 0 - ce sera déroutant pour l'utilisateur lorsqu'elle sera affichée dans l'interface graphique Long- lorsqu'elle n'est pas initialisée, elle sera définie sur null- cette valeur nulle n'apparaîtra pas dans l'interface graphique.Cela s'applique Booleanégalement là où les valeurs peuvent être plus déroutantes lorsque nous utilisons une primitive boolean(car la valeur par défaut est false).
Les collections sont le cas typique pour les objets wrapper Java simples. Cependant, vous pouvez envisager de donner au Wrapper une signification plus spécifique dans le code (objet de valeur).
À mon humble avis, il y a presque toujours un avantage à utiliser des objets de valeur quand cela se résume à la lisibilité et à la maintenance du code. L'emballage de structures de données simples à l'intérieur d'objets lorsqu'ils ont certaines responsabilités simplifie souvent le code. C'est quelque chose de très important dans la conception pilotée par domaine .
Il y a bien sûr le problème de la performance, mais j'ai tendance à l'ignorer jusqu'à ce que j'aie la possibilité de mesurer la performance avec des données appropriées et de faire des actions plus dirigées vers la zone problématique. Il peut également être plus facile de comprendre le problème de performances si le code est également facile à comprendre.
les performances des 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 le wrapper, le choix préféré est d'appeler la méthode equals ().
"Les types primitifs sont considérés comme nuisibles" parce qu'ils mélangent "la sémantique procédurale dans un modèle orienté objet par ailleurs uniforme.
De nombreux programmeurs initialisent les nombres à 0 (par défaut) ou -1 pour signifier cela, mais selon le scénario, cela peut être incorrect ou trompeur.
Si vous souhaitez utiliser des collections, vous devez utiliser des classes Wrapper.
Les types primitifs sont utilisés pour les tableaux. De plus, pour représenter des données sans comportement, par exemple, un compteur ou une condition booléenne.
Depuis l'autoboxing, la frontière "quand utiliser une primitive ou un wrapper" est devenue assez floue.
Mais rappelez-vous que les wrappers sont des objets, vous bénéficiez donc de 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 souhaitez créer un type valeur. Quelque chose comme un ProductSKU ou AirportCode.
Lorsqu'un type primitif (chaîne dans mes exemples) définit l'égalité, vous voudrez remplacer l'égalité.
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 chacun des types de données primitifs.
Toutes les classes Wrapper sont finales. L'objet de toutes les classes wrapper qui peuvent être initié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'englobe aucune valeur primitive et n'est pas initiable. Il n'a pas de constructeur public, il désigne simplement un objet de classe représentant le mot-clé void.