Pourquoi les collections Java ne suppriment-elles pas les méthodes génériques?

Pourquoi Collection.remove (Object o) n'est-il pas générique?

On dirait que Collection<E>j'aurais puboolean remove(E o);

Ensuite, lorsque vous essayez accidentellement de supprimer (par exemple) Set<String>au lieu de chaque chaîne individuelle de a Collection<String>, ce serait une erreur de compilation au lieu d'un problème de débogage plus tard.

Josh Bloch et Bill Pugh font référence à ce problème dans Java Puzzlers IV: The Phantom Reference Menace, Attack of the Clone et Revenge of The Shift .

Josh Bloch dit (6:41) qu'ils ont tenté de générer la méthode get de Map, la méthode remove et une autre, mais "cela n'a tout simplement pas fonctionné".

Il y a trop de programmes raisonnables qui ne pourraient pas être générés si vous n'autorisez que le type générique de la collection comme type de paramètre. L'exemple qu'il donne est une intersection de a Listde Numbers et de a Listde Longs.

remove()(in Mapainsi que in Collection) n'est pas générique car vous devriez pouvoir passer n'importe quel type d'objet à remove(). L'objet supprimé n'a pas besoin d'être du même type que l'objet auquel vous passez remove(); il faut seulement qu'ils soient égaux. De la spécification de remove(), remove(o)supprime l'objet etel qu'il (o==null ? e==null : o.equals(e))est true. Notez qu'il n'y a rien d'exiger oet ed'être du même type. Cela découle du fait que la equals()méthode prend un Objectparamètre as, pas seulement le même type que l'objet.

Bien qu'il puisse être communément vrai que de nombreuses classes se soient equals()définies de sorte que ses objets ne puissent être égaux qu'aux objets de sa propre classe, ce n'est certainement pas toujours le cas. Par exemple, la spécification de List.equals()indique que deux objets List sont égaux s'ils sont tous les deux des Lists et ont le même contenu, même s'il s'agit d'implémentations différentes de List. Donc, pour revenir à l'exemple de cette question, il est possible d'avoir un Map<ArrayList, Something>et pour moi d'appeler remove()avec un LinkedListcomme argument, et cela devrait supprimer la clé qui est une liste avec le même contenu. Cela ne serait pas possible s'il remove()était générique et restreint son type d'argument.

Parce que si votre paramètre de type est un caractère générique, vous ne pouvez pas utiliser une méthode de suppression générique.

Il me semble me souvenir d'avoir rencontré cette question avec la méthode get (Object) de Map. La méthode get dans ce cas n'est pas générique, bien qu'elle devrait raisonnablement s'attendre à recevoir un objet du même type que le premier paramètre de type. J'ai réalisé que si vous transmettez Maps avec un caractère générique comme premier paramètre de type, il n'y a aucun moyen d'extraire un élément de la carte avec cette méthode, si cet argument était générique. Les arguments génériques ne peuvent pas vraiment être satisfaits, car le compilateur ne peut pas garantir que le type est correct. Je suppose que la raison pour laquelle ajouter est générique est que vous devez garantir que le type est correct avant de l'ajouter à la collection. Cependant, lors de la suppression d'un objet, si le type est incorrect, il ne correspondra à rien de toute façon.

Je ne l'ai probablement pas très bien expliqué, mais cela me semble assez logique.

En plus des autres réponses, il y a une autre raison pour laquelle la méthode devrait accepter un Object, qui est des prédicats. Considérez l'exemple suivant:

class Person {
    public String name;
    // override equals()
}
class Employee extends Person {
    public String company;
    // override equals()
}
class Developer extends Employee {
    public int yearsOfExperience;
    // override equals()
}

class Test {
    public static void main(String[] args) {
        Collection<? extends Person> people = new ArrayList<Employee>();
        // ...

        // to remove the first employee with a specific name:
        people.remove(new Person(someName1));

        // to remove the first developer that matches some criteria:
        people.remove(new Developer(someName2, someCompany, 10));

        // to remove the first employee who is either
        // a developer or an employee of someCompany:
        people.remove(new Object() {
            public boolean equals(Object employee) {
                return employee instanceof Developer
                    || ((Employee) employee).company.equals(someCompany);
        }});
    }
}

Le fait est que l'objet passé à la removeméthode est responsable de la définition de la equalsméthode. Construire des prédicats devient très simple de cette façon.

Supposons que l' on a une collection de Cat, et quelques références d'objets de types Animal, Cat, SiameseCatet Dog. Demander à la collection si elle contient l'objet auquel se réfère la Catou la SiameseCatréférence semble raisonnable. Demander s'il contient l'objet auquel la Animalréférence fait référence peut sembler douteux, mais cela reste parfaitement raisonnable. L'objet en question pourrait, après tout, être unCat , et pourrait apparaître dans la collection.

De plus, même si l'objet se trouve être autre chose qu'un Cat, il n'y a aucun problème à dire s'il apparaît dans la collection - répondez simplement "non, ce n'est pas le cas". Une collection "lookup-style" d'un certain type devrait être capable d'accepter de manière significative la référence de n'importe quel supertype et de déterminer si l'objet existe dans la collection. Si la référence d'objet transmise est d'un type non lié, il n'y a aucun moyen que la collection puisse la contenir, donc la requête n'est pas significative dans un certain sens (elle répondra toujours "non"). Néanmoins, comme il n'y a aucun moyen de restreindre les paramètres à des sous-types ou des supertypes, il est plus pratique d'accepter simplement n'importe quel type et de répondre "non" pour tous les objets dont le type n'est pas lié à celui de la collection.

J'ai toujours pensé que c'était parce que remove () n'avait aucune raison de se soucier du type d'objet que vous lui donniez. Il est assez facile, peu importe, de vérifier si cet objet est l'un de ceux que contient la collection, car il peut appeler equals () sur n'importe quoi. Il est nécessaire de vérifier le type sur add () pour s'assurer qu'il ne contient que des objets de ce type.

C'était un compromis. Les deux approches ont leur avantage:

• remove(Object o)
  • est plus flexible. Par exemple, il permet de parcourir une liste de nombres et de les supprimer d'une liste de longs.
  • le code qui utilise cette flexibilité peut être plus facilement généré
• remove(E e) apporte plus de sécurité de type à ce que la plupart des programmes veulent faire en détectant des bogues subtils au moment de la compilation, comme essayer par erreur de supprimer un entier d'une liste de courts-circuits.

La rétrocompatibilité a toujours été un objectif majeur lors de l'évolution de l'API Java, c'est pourquoi remove (Object o) a été choisi car il facilitait la génération du code existant. Si la rétrocompatibilité n'avait PAS été un problème, je suppose que les concepteurs auraient choisi remove (E e).

Remove n'est pas une méthode générique de sorte que le code existant utilisant une collection non générique sera toujours compilé et aura toujours le même comportement.

Voir http://www.ibm.com/developerworks/java/library/j-jtp01255.html pour plus de détails.

Edit: un commentateur demande pourquoi la méthode add est générique. [... supprimé mon explication ...] Le deuxième commentateur a répondu à la question de firebird84 bien mieux que moi.

Une autre raison est à cause des interfaces. Voici un exemple pour le montrer:

public interface A {}

public interface B {}

public class MyClass implements A, B {}

public static void main(String[] args) {
   Collection<A> collection = new ArrayList<>();
   MyClass item = new MyClass();
   collection.add(item);  // works fine
   B b = item; // valid
   collection.remove(b); /* It works because the remove method accepts an Object. If it was generic, this would not work */
}

Parce que cela briserait le code existant (pré-Java5). par exemple,

Set stringSet = new HashSet();
// do some stuff...
Object o = "foobar";
stringSet.remove(o);

Maintenant, vous pourriez dire que le code ci-dessus est faux, mais supposons que o provienne d'un ensemble hétérogène d'objets (c'est-à-dire qu'il contenait des chaînes, des nombres, des objets, etc.). Vous voulez supprimer toutes les correspondances, ce qui était légal car remove ignorait simplement les non-chaînes car elles n'étaient pas égales. Mais si vous le supprimez (String o), cela ne fonctionne plus.