Je stocke des objets entiers représentant un index des objets que je veux suivre. Plus tard dans mon code, je veux vérifier si l'indice d'un objet particulier correspond à l'un de ces entiers que j'ai stockés précédemment. Je le fais en créant une arraylist et crée un nouveau nombre d'entiers à partir de l'index de A pour boucle: i, je veux ensuite vérifier plus tard si la liste contient un index particulier: P> //Cycle through the namedNodeMap array to find each of the course codes
for(int i=0; i<numberElementsInNodeList; i++) {
if(!courseselectItems.contains(new Integer(i))) {
//Do Stuff
}
}
7 Réponses :
Oui, vous pouvez utiliser Aussi, en raison de la boxe automatique, vous pouvez simplement écrire: p> Il convient de mentionner que: P> list.Contains () code> comme utilisé
Equals () code> et un
integer code> prend en charge que lors de la comparaison à d'autres entier code> s.
ArrayList<Integer> courseselectItems = new ArrayList();
Merci! Y a-t-il une raison particulière pour que je veux faire mes variables du type d'interface et non le type de béton?
@Thechiman Le type concret est un détail de mise en œuvre. En règle générale i> Paramètres, les variables locales et les membres de la classe doivent être l'interface afin que vous n'ayez pas lié à une implémentation particulière. Il vous permet, par exemple, plugin une liste de liste code> personnalisée code> à un point ultérieur, etc.
Ce n'est pas si important si la liste code> est complètement privée à la classe, visible nulle part ailleurs. Mais si vous l'exposez d'une certaine manière (par exemple, la classe contenant la liste a une méthode pour renvoyer la liste), vous devez absolument le retourner sous forme de liste
code> et non comme un
ArrayList code>. Vous pouvez décider plus tard, par exemple, que
linkedlist code> est une implémentation plus appropriée.
Réponse courte est oui, vous devriez être capable de faire arraylist.Contains (nouveau entier (14)) code>, par exemple, pour voir si 14 est dans la liste. La raison est que l'entier remplace le
est égal à la méthode code> pour se comparer correctement à d'autres instances avec la même valeur. P>
Oui, il sera, parce que list.contains () code> Utilisez la méthode
Equals () code> de l'objet à comparer. Et
integer.equals () code> comparent la valeur entière. P>
Oui, la boxe automatique se produit, mais cela entraîne une pénalité de performance. Ce n'est pas clair de votre exemple pourquoi vous voudriez résoudre le problème de cette manière. P>
Aussi, en raison de la boxe, la création de la classe entier à la main est superflue. P>
Comme Cletus et DJ mentionné, votre approche fonctionnera.
Je ne connais pas le contexte de votre code, mais si vous vous souciez de l'index particulier, considérons également le style suivant: P>
J'ai fini par changer de code pour faire quelque chose de similaire à celui-ci. Merci!
Je pose ma réponse sous la forme d'un test (passant), comme exemple de la façon dont vous pourriez rechercher cela vous-même. Pour ne pas vous décourager de l'utiliser, c'est génial - juste pour essayer de promouvoir Tests de caractérisation . < Pré> xxx pré> p>
Ouais, maintenant que j'y pense, j'aurais pu me tester facilement cela. Heh, je me sens muet. Merci. :)
Ma question est, quand je crée un nouveau entier en utilisant les nouvelles Entier (i) que je pourrai être en mesure de comparer des entiers en utilisant ArrayList.contains ()? C'est-à-dire, quand je crée un nouvel objet à l'aide new Integer (i), que ce sera le même que l'objet entier précédemment créé si la valeur int utilisée pour les créer sont les mêmes? P> blockQuote>
La réponse courte est oui. P>
La longue réponse est ... p>
C'est-à-dire quand je crée un nouvel objet à l'aide new Integer (i), que les mêmes que em> l'objet Entier précédemment créé si la valeur int utilisée pour les créer sont les mêmes ? p> blockQuote>
Je suppose que vous voulez dire "... que ce sera la même instance strong> comme ..." em>? La réponse est pas strong> -. Appeler
nouveau code> sera toujours créer une instance distincte distincte de l'instance précédente, même si les paramètres du constructeur sont identiques p>
Cependant, malgré séparés identité em>, ces deux objets auront valeur équivalente em>, à savoir appeler equals () entre eux retourne vrai. P>
Collection.contains () strong> p>
Il se trouve que d'avoir des instances distinctes de valeur équivalente ( equals () retourne true em>) est correct.
.contains () Méthode code> est en
Collection code> interface. La description de Javadoc
.contains () code> dit: p>
http://java.sun.com/javase/6/docs/api/java/util/Collection.html#contains(java.lang.Object) p>
booléen contient (Object o) strong> p>
Renvoie true si cette collection contient l'élément spécifié. Suite formellement, retourne vrai si et seulement si cette collection contient au moins un de telle sorte que l'élément e (o == null? e == null :. o.equals (e)) em> p> blockQuote> blockQuote>
Ainsi, il fera ce que vous voulez. P>
Structure de données strong> p>
Vous devriez également considérer si vous avez la structure de données droit. P>
La liste uniquement à propos de confinement? est l'ordre important? Avez-vous souciez de doublons? Étant donné que la liste est l'ordre, à l'aide d'une liste peut laisser entendre que vos soucis de code sur commande. Ou que vous avez besoin de maintenir des doublons dans la structure de données. P>
Cependant, si l'ordre n'a pas d'importance, si vous ne voulez pas ou n'aurez pas les doublons, et si vous utilisez vraiment que cette structure de données pour vérifier si contient une valeur spécifique, puis em> pourrait vous demander si vous devez utiliser un ensemble < / a> au lieu. p>
Sur un Sidenote, voici quelque chose qui vaut la peine de savoir des entiers et des chaînes: devx.com/tips/tip/42276