ICollection Interfaz
Definición
Importante
Parte de la información hace referencia a la versión preliminar del producto, que puede haberse modificado sustancialmente antes de lanzar la versión definitiva. Microsoft no otorga ninguna garantía, explícita o implícita, con respecto a la información proporcionada aquí.
Interfaz raíz de la jerarquía de colecciones.
[Android.Runtime.Register("java/util/Collection", "", "Java.Util.ICollectionInvoker")]
[Java.Interop.JavaTypeParameters(new System.String[] { "E" })]
public interface ICollection : IDisposable, Java.Interop.IJavaPeerable, Java.Lang.IIterable[<Android.Runtime.Register("java/util/Collection", "", "Java.Util.ICollectionInvoker")>]
[<Java.Interop.JavaTypeParameters(new System.String[] { "E" })>]
type ICollection = interface
interface IIterable
interface IJavaObject
interface IDisposable
interface IJavaPeerable- Derivado
- Atributos
- Implementaciones
Comentarios
Interfaz raíz de la jerarquía de colecciones. Una colección representa un grupo de objetos, conocido como sus elementos. Algunas colecciones permiten elementos duplicados y otros no. Algunos están ordenados y otros sin ordenar. El JDK no proporciona implementaciones directas de esta interfaz: proporciona implementaciones de subinterfaces más específicas, como Set y List. Esta interfaz se usa normalmente para pasar colecciones y manipularlas donde se desee la generalidad máxima.
Los contenedores o conjuntos múltiples (colecciones desordenadas que pueden contener elementos duplicados) deben implementar esta interfaz directamente.
Todas las clases de implementación de uso Collection general (que normalmente implementan Collection indirectamente a través de una de sus subinterfaces) deben proporcionar dos constructores "estándar": un constructor void (sin argumentos), que crea una colección vacía y un constructor con un único argumento de tipo Collection, que crea una nueva colección con los mismos elementos que su argumento. En efecto, el último constructor permite al usuario copiar cualquier colección, generando una colección equivalente del tipo de implementación deseado. No hay ninguna manera de aplicar esta convención (ya que las interfaces no pueden contener constructores), pero todas las implementaciones de uso Collection general de las bibliotecas de la plataforma Java cumplen.
Algunos métodos se especifican como opcionales. Si una implementación de recopilación no implementa una operación determinada, debe definir el método correspondiente para iniciar UnsupportedOperationException. Estos métodos se marcan como "operación opcional" en las especificaciones de método de las interfaces de colecciones.
"optional-restrictions">Algunas implementaciones de colección tienen restricciones en los elementos que pueden contener. Por ejemplo, algunas implementaciones prohíben elementos NULL y algunas tienen restricciones sobre los tipos de sus elementos. Si se intenta agregar un elemento no apto, se produce una excepción no desactivada, normalmente NullPointerException o ClassCastException. Si se intenta consultar la presencia de un elemento no apto, se puede producir una excepción o simplemente devolver false; algunas implementaciones mostrarán el comportamiento anterior y algunas mostrarán esta última. Por lo general, intentar una operación en un elemento no apto cuya finalización no daría lugar a la inserción de un elemento no apto en la colección puede producir una excepción o puede realizarse correctamente, en la opción de la implementación. Estas excepciones se marcan como "opcionales" en la especificación de esta interfaz.
Es hasta cada colección para determinar su propia directiva de sincronización. En ausencia de una garantía más sólida por parte de la implementación, el comportamiento indefinido puede deberse a la invocación de cualquier método en una colección mutada por otro subproceso; Esto incluye invocaciones directas, pasando la colección a un método que podría realizar invocaciones y usando un iterador existente para examinar la colección.
Muchos métodos de las interfaces de Collections Framework se definen en términos del Object#equals(Object) equals método . Por ejemplo, la especificación del #contains(Object) contains(Object o) método dice: "devuelve true si y solo si esta colección contiene al menos un elemento e de este modo que (o==null ? e==null : o.equals(e))". Esta especificación no debe interpretarse para implicar que la invocación Collection.contains con un argumento o que no sea NULL hará o.equals(e) que se invoque para cualquier elemento e. Las implementaciones son gratuitas para implementar optimizaciones en las que se evita la equals invocación, por ejemplo, comparando primero los códigos hash de los dos elementos. (La Object#hashCode() especificación garantiza que dos objetos con códigos hash distintos no pueden ser iguales). Por lo general, las implementaciones de las distintas interfaces de Collections Framework son libres de aprovechar el comportamiento especificado de los métodos subyacentes Object siempre que el implementador lo considere adecuado.
Algunas operaciones de recopilación que realizan un recorrido recursivo de la colección pueden producir un error con una excepción para las instancias autoreferenciales en las que la colección se contiene directa o indirectamente. Esto incluye los clone()métodos , equals()hashCode() y toString() . Las implementaciones pueden controlar opcionalmente el escenario autoreferencial, pero la mayoría de las implementaciones actuales no lo hacen.
<h2>"view">View Collections</h2>
La mayoría de las colecciones administran el almacenamiento de los elementos que contienen. Por el contrario, las colecciones de vistas no almacenan elementos, sino que se basan en una colección de respaldo para almacenar los elementos reales. Las operaciones no controladas por la propia colección de vistas se delegarán en la colección de respaldo. Entre los ejemplos de colecciones de vistas se incluyen las colecciones contenedoras devueltas por métodos como Collections#checkedCollection Collections.checkedCollection, Collections#synchronizedCollection Collections.synchronizedCollectiony Collections#unmodifiableCollection Collections.unmodifiableCollection. Otros ejemplos de colecciones de vistas incluyen colecciones que proporcionan una representación diferente de los mismos elementos, por ejemplo, según lo proporcionado por List#subList List.subList, NavigableSet#subSet NavigableSet.subSeto Map#entrySet Map.entrySet. Los cambios realizados en la colección de respaldo son visibles en la colección de vistas. En consecuencia, los cambios realizados en la colección de vistas — si se permiten cambios — se escriben en la colección de respaldo. Aunque técnicamente no son colecciones, las instancias de y ListIterator también pueden permitir que las modificaciones se escriban en la colección de respaldo y, en algunos casos, las modificaciones en la colección de Iterator respaldo serán visibles para el Iterador durante la iteración.
<h2>"unmodifiable">Colecciones no modificables</h2>
Algunos métodos de esta interfaz se consideran "destructivos" y se denominan métodos "mutadores" en que modifican el grupo de objetos contenidos dentro de la colección en la que operan. Se pueden especificar para iniciar UnsupportedOperationException si esta implementación de recopilación no admite la operación. Estos métodos deben producir (pero no son necesarios) si UnsupportedOperationException la invocación no tendría ningún efecto en la colección. Por ejemplo, considere una colección que no admite la #add add operación. ¿Qué ocurrirá si el #addAll addAll método se invoca en esta colección, con una colección vacía como argumento? La adición de cero elementos no tiene ningún efecto, por lo que es permisible para esta colección simplemente no hacer nada y no producir una excepción. Sin embargo, se recomienda que estos casos inicien una excepción incondicionalmente, ya que solo producir en determinados casos puede provocar errores de programación.
Una colección no modificable es una colección, todos cuyos métodos mutadores (como se definió anteriormente) se especifican para iniciar UnsupportedOperationException. Por lo tanto, esta colección no se puede modificar llamando a ningún método en ella. Para que una colección no se pueda modificar correctamente, las colecciones de vistas derivadas de ella también deben no modificarse. Por ejemplo, si una lista no se puede modificar, la lista devuelta por List#subList List.subList también no se puede modificar.
Una colección no modificable no es necesariamente inmutable. Si los elementos contenidos son mutables, toda la colección es claramente mutable, aunque podría no modificarse. Por ejemplo, considere dos listas no modificables que contienen elementos mutables. El resultado de la llamada list1.equals(list2) puede diferir de una llamada a la siguiente si los elementos se han mutado, aunque ambas listas no sean modificables. Sin embargo, si una colección no modificable contiene todos los elementos inmutables, se puede considerar inmutable de forma eficaz.
<h2>"unmodview">Colecciones de vistas< no modificables/h2>
Una colección de vistas no modificable es una colección que no se puede modificar y que también es una vista de una colección de respaldo. Sus métodos mutadores inician UnsupportedOperationException, como se ha descrito anteriormente, mientras que los métodos de lectura y consulta se delegan en la colección de respaldo. El efecto es proporcionar acceso de solo lectura a la colección de respaldo. Esto resulta útil para que un componente proporcione a los usuarios acceso de lectura a una colección interna, a la vez que les impide modificar dichas colecciones inesperadamente. Algunos ejemplos de colecciones de vistas no modificables son los devueltos por los Collections#unmodifiableCollection Collections.unmodifiableCollectionmétodos relacionados , Collections#unmodifiableList Collections.unmodifiableListy .
Tenga en cuenta que los cambios en la colección de respaldo pueden seguir siendo posibles y, si se producen, son visibles a través de la vista no modificable. Por lo tanto, una colección de vistas no modificable no es necesariamente inmutable. Sin embargo, si la colección de respaldo de una vista no modificable es inmutable de forma eficaz, o si la única referencia a la colección de respaldo es a través de una vista no modificable, la vista se puede considerar inmutable de forma eficaz.
<h2>"serializable">Serializability of Collections</h2>
La serialización de colecciones es opcional. Por lo tanto, ninguna de las interfaces de colecciones se declara para implementar la java.io.Serializable interfaz. Sin embargo, la serialización se considera generalmente útil, por lo que la mayoría de las implementaciones de colección son serializables.
Las implementaciones de colección que son clases públicas (como ArrayList o HashMap) se declaran para implementar la Serializable interfaz si de hecho son serializables. Algunas implementaciones de colecciones no son clases públicas, como las colecciones no modificables. En tales casos, la serialización de dichas colecciones se describe en la especificación del método que los crea o en algún otro lugar adecuado. En los casos en los que no se especifica la serialización de una colección, no hay ninguna garantía sobre la serialización de dichas colecciones. En concreto, muchas colecciones de vistas no son serializables.
No se puede garantizar que una implementación de colección que implemente la Serializable interfaz sea serializable. El motivo es que, en general, las colecciones contienen elementos de otros tipos y no es posible determinar estáticamente si las instancias de algún tipo de elemento son realmente serializables. Por ejemplo, considere una serializable Collection<E>, donde E no implementa la Serializable interfaz . La colección puede ser serializable, si solo contiene elementos de algún subtipo serializable de E, o si está vacío. Por lo tanto, se dice que las colecciones son serializables condicionalmente, ya que la serialización de la colección en su conjunto depende de si la propia colección es serializable y de si todos los elementos contenidos también son serializables.
Se produce un caso adicional con instancias de SortedSet y SortedMap. Estas colecciones se pueden crear con un Comparator objeto que impone una ordenación en los elementos establecidos o claves de asignación. Esta colección solo se puede serializar si el proporcionado Comparator también es serializable.
Esta interfaz es miembro de Java Collections Framework.
Se agregó en la versión 1.2.
Documentación de Java para java.util.Collection.
Las partes de esta página son modificaciones basadas en el trabajo creado y compartido por el proyecto de código y se usan según los términos descritos en la creative Commons 2.5.
Propiedades
| Handle |
Obtiene el valor JNI del objeto Android subyacente. (Heredado de IJavaObject) |
| IsEmpty |
Devuelve si no |
| JniIdentityHashCode |
Devuelve el valor de |
| JniManagedPeerState |
Estado del mismo nivel administrado. (Heredado de IJavaPeerable) |
| JniPeerMembers |
Compatibilidad con la invocación y el acceso a miembros. (Heredado de IJavaPeerable) |
| PeerReference |
Devuelve una JniObjectReference de la instancia de objeto java ajustada. (Heredado de IJavaPeerable) |
Métodos
| Add(Object) |
Garantiza que esta colección contiene el elemento especificado (operación opcional). |
| AddAll(ICollection) |
Agrega todos los elementos de la colección especificada a esta colección (operación opcional). |
| Clear() |
Quita todos los elementos de esta colección (operación opcional). |
| Contains(Object) |
Devuelve |
| ContainsAll(ICollection) |
Devuelve |
| Disposed() |
Se llama cuando se ha eliminado la instancia. (Heredado de IJavaPeerable) |
| DisposeUnlessReferenced() |
Si no hay referencias pendientes a esta instancia, llama a |
| Equals(Object) |
Compara el objeto especificado con esta colección para obtener igualdad. |
| Finalized() |
Se llama cuando se ha finalizado la instancia. (Heredado de IJavaPeerable) |
| ForEach(IConsumer) |
Realiza la acción especificada para cada elemento de |
| GetHashCode() |
Devuelve el valor de código hash de esta colección. |
| Iterator() |
Devuelve un iterador sobre los elementos de esta colección. |
| Remove(Object) |
Quita una única instancia del elemento especificado de esta colección, si está presente (operación opcional). |
| RemoveAll(ICollection) |
Quita todos los elementos de esta colección que también están incluidos en la colección especificada (operación opcional). |
| RemoveIf(IPredicate) |
Quita todos los elementos de esta colección que satisfacen el predicado especificado. |
| RetainAll(ICollection) |
Conserva solo los elementos de esta colección contenidos en la colección especificada (operación opcional). |
| SetJniIdentityHashCode(Int32) |
Establezca el valor devuelto por |
| SetJniManagedPeerState(JniManagedPeerStates) |
Interfaz raíz de la jerarquía de colecciones. (Heredado de IJavaPeerable) |
| SetPeerReference(JniObjectReference) |
Establezca el valor devuelto por |
| Size() |
Devuelve el número de elementos de esta colección. |
| Spliterator() |
Crea un |
| ToArray() |
Devuelve una matriz que contiene todos los elementos de esta colección. |
| ToArray(IIntFunction) |
Devuelve una matriz que contiene todos los elementos de esta colección, utilizando la función proporcionada |
| ToArray(Object[]) |
Devuelve una matriz que contiene todos los elementos de esta colección; el tipo en tiempo de ejecución de la matriz devuelta es el de la matriz especificada. |
| UnregisterFromRuntime() |
Anule el registro de esta instancia para que el entorno de ejecución no lo devuelva de Java.Interop.JniRuntime+JniValueManager.PeekValue futuras invocaciones. (Heredado de IJavaPeerable) |
Implementaciones de interfaz explícitas
| IIterable.Spliterator() |
Crea un |
Métodos de extensión
| JavaCast<TResult>(IJavaObject) |
Realiza una conversión de tipos comprobados en tiempo de ejecución de Android. |
| JavaCast<TResult>(IJavaObject) |
Interfaz raíz de la jerarquía de colecciones. |
| GetJniTypeName(IJavaPeerable) |
Interfaz raíz de la jerarquía de colecciones. |
| ToEnumerable(IIterable) |
Interfaz raíz de la jerarquía de colecciones. |
| ToEnumerable<T>(IIterable) |
Interfaz raíz de la jerarquía de colecciones. |