Est-ce que shallAll () et KeepAll () dans la cardinalité de l'adresse de l'interface Collection?

Question

En Java, les éléments includesAll et retenueAll de la classe AbstractCollection indiquent explicitement que la cardinalité n'est pas respectée. En d'autres termes, le nombre d'instances d'une valeur de chaque côté n'a pas d'importance. Etant donné que toutes les collections Java de la bibliothèque standard étendent AbstractCollection, il est supposé que toutes fonctionnent de la même manière.

Cependant, la documentation de ces méthodes dans l'interface Collection ne dit rien. Est-ce qu'on est supposé déduire de AbstractCollection, ou cela a-t-il été laissé exprès pour permettre de définir des collections qui fonctionnent différemment?

Par exemple, Bag in apache-collections indique explicitement qu'il respecte la cardinalité et prétend que cela enfreint le contrat de la version de Collection (même si ce n'est pas le cas).

Alors, quelle est la sémantique de ces opérations dans Collection plutôt que dans AbstractCollection?

Edit: Bien que ceux qui se demandent pourquoi je voudrais m'en soucier, c'est parce que dans le cadre de mon doctorat J'ai démontré que les développeurs ne s'attendent pas à une violation de la conformité dans Apache, mais j'essaie de comprendre pourquoi l'interface Collection est si ambiguë.

Answer 1

Les javadocs de includesAll (dans Collection) disent:

  

Retourne: true si cette collection   contient tous les éléments du   collection spécifiée

et pour keepAll (dans Collection):

  

Ne conserve que les éléments de cette   collection qui sont contenus dans la   collection spécifiée (facultatif   opération). En d'autres termes, supprime   de cette collection tous ses   éléments qui ne sont pas contenus dans le   collection spécifiée.

J'ai lu, dans le contrat contientAll, cela signifie que l'appel de a.containsAll (b) renverra true, si et seulement si, l'appelant a.contains (bElem) pour chaque élément bElem dans b renverrait true. Je suppose également que cela implique que a.containsAll (someEmptyCollection) renvoie également true. Au fur et à mesure que vous énoncez les javadocs de AbstractCollection, déclarez plus explicitement ceci:

  

Cette implémentation itère sur le   collection spécifiée, en vérifiant chaque   élément retourné par l'itérateur dans   tournez pour voir si elle est contenue dans cette   collection. Si tous les éléments sont si   true est renvoyé, sinon   faux.

Je conviens que le contact pour la collection pour contient devrait être plus explicite pour éviter toute possibilité de confusion. (Et que la lecture des javadocs pour AbstractCollection n'aurait PAS été nécessaire pour confirmer sa compréhension de Collection)

Je n’aurais pas émis d’hypothèse concernant le nombre d’éléments en double après un appel à conserverAll. Le contrat indiqué dans Collection (d'après ce que j'ai lu) n'implique en aucun cas la manière dont les doublons dans l'une ou l'autre collection seraient traités. D'après mes lectures de keepAll dans la collection, plusieurs résultats possibles de a.retainAll (b) sont raisonnables:

1. résultat contient 1 de chaque élément ayant au moins une copie à la fois a et b
2. résultat contient chaque élément (y compris les doublons) qui était dans a, à l'exception de ceux qui ne sont pas dans b
3. ou même, le résultat contient quelque part entre 1 et le nombre de copies trouvées dans a de chaque élément dans a, à l'exception de celles ne figurant pas dans b. Je me serais attendu à ce que soit n ° 1 ou n ° 2, mais supposerais que l’un des trois soit légal sur la base du contrat.

Les javadocs de AbstractCollection confirment qu'il utilise # 2:

  

Cette implémentation itère sur cette   collection, vérification de chaque élément   retourné par l'itérateur à son tour   voir si il est contenu dans le spécifié   collection. Si ce n'est pas si contenu,   il est retiré de cette collection avec   la méthode remove de l'itérateur

Bien que ceci ne soit pas dans ma lecture du contrat de l'interface originale de Collection, je ne supposerais pas nécessairement que le comportement de Collection était généralement le même.

Peut-être devriez-vous envisager de soumettre les mises à jour suggérées à JavaDoc une fois que vous avez terminé.

Quant à la question de savoir pourquoi l'interface de la collection a été laissée si ambiguë - je doute fort que cela ait été fait intentionnellement - c'est probablement quelque chose qui n'a pas reçu la priorité qui lui était due lors de l'écriture de cette partie de l'API.

Answer 2

Je ne pense pas que Collection le définisse de cette façon ni d'une autre, mais il est simplement devenu une sorte de convention pour suivre le comportement de AbstractCollection, par exemple google-collections à faire: voir leur documentation Multiset (" Multiset "est ce qu'ils appellent un" sac ")