¿ContenidosAll () y retenerAll () en la cardinalidad de la dirección de la interfaz de la Colección?

Question

En Java, el contenido contiene Todos y Retener Todos en la clase AbstractCollection declara explícitamente que no se respeta la cardinalidad, por lo que en otras palabras, no importa cuántas instancias de un valor haya en cada lado. Dado que todas las colecciones de Java en la biblioteca estándar extienden AbstractCollection, se supone que todas funcionan de la misma manera.

Sin embargo, la documentación de estos métodos en la interfaz de la Colección no dice nada. ¿Se supone que se debe inferir de AbstractCollection o no se especificó a propósito para permitir que se definan colecciones que funcionan de manera diferente?

Por ejemplo, Bag in apache-collections declara explícitamente que respeta la cardinalidad y afirma que viola el contrato de la versión de Collection (aunque en realidad no lo hace).

Entonces, ¿cuáles son las semánticas de estas operaciones en la Colección en lugar de en AbstractCollection?

Edit: Tho aquellos que se preguntan por qué me importaría, es porque como parte de mi Ph.D. trabajo demostré que los desarrolladores no esperan la infracción de conformidad en Apache, pero estoy tratando de entender por qué la interfaz de la Colección se dejó tan ambigua.

Answer 1

Los javadocs para contiene todos (en la colección) dicen:

  

Devuelve: verdadero si esta colección   contiene todos los elementos en el   colección especificada

y para retainAll (en Colección):

  

Retiene solo los elementos en este   colección contenida en el   colección especificada (opcional   operación). En otras palabras, elimina   de esta colección todos sus   Elementos que no están contenidos en el   colección especificada.

Leí contiene el contrato de AllAll que significa que llamar a a.containsAll (b) devolverá verdadero, si y solo si, llamar a a.contains (bElem) para cada elemento bElem en b devolvería verdadero. También supongo que a.containsAll (someEmptyCollection) también devolverá true. A medida que declaras los javadocs para AbstractCollection, explícalo más explícitamente:

  

Esta implementación itera sobre el   colección especificada, comprobando cada   elemento devuelto por el iterador en   voltear para ver si está contenido en este   colección. Si todos los elementos son así   contenido verdadero se devuelve, de lo contrario   falso.

Estoy de acuerdo en que el contacto para Colección para contiene Todos debería ser más explícito para evitar cualquier posibilidad de confusión. (Y que la lectura de los javadocs para AbstractCollection NO debería haber sido necesaria para confirmar la comprensión de la Colección)

No habría hecho una suposición con respecto al número de elementos duplicados después de una llamada para retener Todos. El contrato establecido en la Colección (según mi lectura) no implica de ninguna manera cómo se manejarían los duplicados en cualquiera de las colecciones. Según mi lectura de RetenAll en la colección, todos los posibles resultados de a.retainAll (b) son razonables:

El resultado
1. contiene 1 de cada elemento que tiene al menos una copia en ayb
2. el resultado contiene cada elemento (incluidos los duplicados) que estaba en a, excepto los que no están en b
3. o incluso, el resultado contiene entre 1 y el número de copias encontradas en a de cada elemento en a, excepto las que no están en b. Habría esperado el # 1 o el # 2, pero asumiría que cualquiera de los tres es legal en función del contrato.

Los javadocs para AbstractCollection confirman que usa el n. ° 2:

  

Esta implementación itera sobre esto   colección, comprobando cada elemento   devuelto por el iterador a su vez a   ver si está contenido en el especificado   colección. Si no está tan contenido,   se ha eliminado de esta colección con   el método de eliminación del iterador

Aunque como esto no está en mi lectura del contrato de la interfaz de la Colección original, no necesariamente asumo que el comportamiento de la Colección sea generalmente de esta manera.

Quizás debería considerar enviar actualizaciones sugeridas a JavaDoc una vez que haya terminado.

En cuanto a "por qué la interfaz de la Colección se dejó tan ambigua", dudo seriamente que se haya hecho intencionalmente, probablemente solo algo a lo que no se le dio la debida prioridad cuando se escribió esa parte de las API.

Answer 2

No creo que Collection lo defina de esta manera u otra, pero simplemente se convirtió en una especie de convención seguir el comportamiento de AbstractCollection, por ejemplo colecciones de google do: consulte su documentación Multiset (Multiset es lo que llaman una bolsa)