Voici un bel écueil que je viens de rencontrer. Considérons une liste d'entiers :
List<Integer> list = new ArrayList<Integer>();
list.add(5);
list.add(6);
list.add(7);
list.add(1);
Quelle est votre opinion sur ce qui se passe lorsque vous exécutez list.remove(1)
? Qu'en est-il list.remove(new Integer(1))
? Cela peut provoquer des bogues désagréables.
Quelle est la bonne façon de faire la différence entre remove(int index)
qui supprime un élément à partir d'un indice donné et remove(Object o)
qui supprime un élément par référence, lorsqu'il s'agit de listes d'entiers ?
Le point principal à considérer ici est celui @Nikita a mentionné - la correspondance exacte des paramètres a la priorité sur l'auto-boxing.
12 votes
A : le vrai problème ici est que quelqu'un chez Sun a pensé qu'avoir des classes enveloppantes (immuables) autour des primitives était intelligent et plus tard quelqu'un a pensé qu'avoir l'auto-(un)boxing était encore plus intelligent... ET QUE LES GENS CONTINUENT À UTILISER DE MAUVAISES API PAR DÉFAUT QUAND IL EN EXISTE DE MEILLEURES . Pour de nombreuses raisons, il existe bien meilleur solution que nouveau Arraylist<Integer> . Par exemple, Trove fournit des éléments tels que TIntArrayList . Plus je programme en Java (SCJP depuis 2001), moins j'utilise de classes enveloppantes et plus j'utilise des API bien conçues (Trove, Google, etc. me viennent à l'esprit).