IMap Interfaz

Definición

[Android.Runtime.Register("java/util/Map", "", "Java.Util.IMapInvoker")]
[Java.Interop.JavaTypeParameters(new System.String[] { "K", "V" })]
public interface IMap : Android.Runtime.IJavaObject, IDisposable, Java.Interop.IJavaPeerable

[<Android.Runtime.Register("java/util/Map", "", "Java.Util.IMapInvoker")>]
[<Java.Interop.JavaTypeParameters(new System.String[] { "K", "V" })>]
type IMap = interface
    interface IJavaObject
    interface IDisposable
    interface IJavaPeerable

Derivado

Android.Util.ArrayMap

Java.Util.AbstractMap

Java.Util.Concurrent.ConcurrentHashMap

Java.Util.Concurrent.IConcurrentMap

Java.Util.EnumMap

Más…

Atributos

RegisterAttribute JavaTypeParametersAttribute

Implementaciones

IJavaObject IJavaPeerable IDisposable

Comentarios

Objeto que asigna claves a valores. Un mapa no puede contener claves duplicadas; cada clave puede asignarse a un valor como máximo.

Esta interfaz tiene lugar la Dictionary clase , que era una clase totalmente abstracta en lugar de una interfaz.

La Map interfaz proporciona tres vistas de colección, que permiten que el contenido de un mapa se vea como un conjunto de claves, una colección de valores o un conjunto de asignaciones de clave-valor. El orden de un mapa se define como el orden en el que los iteradores de las vistas de colección del mapa devuelven sus elementos. Algunas implementaciones de mapa, como la TreeMap clase , hacen garantías específicas en cuanto a su orden de encuentro; otras, como la HashMap clase, no. Los mapas con un orden de encuentro definido suelen ser subtipos de la SequencedMap interfaz.

Nota: Se debe tener gran cuidado si los objetos mutables se usan como claves de mapa. El comportamiento de un mapa no se especifica si el valor de un objeto se cambia de una manera que afecta a equals las comparaciones mientras el objeto es una clave en el mapa. Un caso especial de esta prohibición es que no se permite que un mapa se contenga como clave. Aunque se permite que un mapa se contenga como un valor, se recomienda extrema precaución: los equals métodos y hashCode ya no están bien definidos en este mapa.

Todas las clases de implementación de mapa de uso general deben proporcionar dos constructores "estándar": un constructor void (sin argumentos) que crea un mapa vacío y un constructor con un único argumento de tipo Map, que crea un nuevo mapa con las mismas asignaciones de clave-valor que su argumento. En efecto, el último constructor permite al usuario copiar cualquier asignación, generando un mapa equivalente de la clase deseada. No hay ninguna manera de aplicar esta recomendación (ya que las interfaces no pueden contener constructores), pero todas las implementaciones de mapa de uso general en el JDK cumplen.

Los métodos "destructivos" contenidos en esta interfaz, es decir, los métodos que modifican el mapa en el que operan, se especifican para iniciar UnsupportedOperationException si este mapa no admite la operación. Si este es el caso, estos métodos pueden, pero no son necesarios, producir un UnsupportedOperationException si la invocación no tendría ningún efecto en el mapa. Por ejemplo, invocar el #putAll(Map) método en un mapa no modificable puede, pero no es necesario, producir la excepción si el mapa cuyas asignaciones se van a "superponer" está vacía.

Algunas implementaciones de mapa tienen restricciones en las claves y los valores que pueden contener. Por ejemplo, algunas implementaciones prohíben las claves y los valores NULL, y algunas tienen restricciones en los tipos de sus claves. Si se intenta insertar una clave o un valor no válidos, se produce una excepción no desactivada, normalmente NullPointerException o ClassCastException. Si intenta consultar la presencia de una clave o un valor no válidos, 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, si se intenta realizar una operación en una clave o un valor no válidos cuya finalización no daría lugar a la inserción de un elemento no apto en el mapa, 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.

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 #containsKey(Object) containsKey(Object key) método indica: "devuelve true si y solo si este mapa contiene una asignación para una clave k de este modo que (key==null ? k==null : key.equals(k))". Esta especificación no debe interpretarse para indicar que la Map.containsKey invocación con un argumento key que no sea NULL provocará key.equals(k) que se invoque para cualquier clave k. 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 las dos claves. (La Object#hashCode() especificación garantiza que dos objetos con códigos hash desiguales 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 asignación que realizan recorridos recursivos del mapa pueden producir un error con una excepción para las instancias autorreferenciales en las que el mapa se contiene directa o indirectamente. Esto incluye los clone()métodos , equals()hashCode() y toString() . Las implementaciones pueden controlar opcionalmente el escenario autorreferencial, pero la mayoría de las implementaciones actuales no lo hacen.

<h2>"unmodifiable">Unmodifiable Maps</h2>

Los Map#of() Map.ofmétodos de fábrica estáticos , Map#ofEntries(Map.Entry...) Map.ofEntriesy Map#copyOf Map.copyOf proporcionan una manera cómoda de crear mapas no modificables. Las Map instancias creadas por estos métodos tienen las siguientes características:

<ul>li Son i inmodifiable</i>.<><> Las claves y los valores no se pueden agregar, quitar ni actualizar. Llamar a cualquier método mutador en el mapa siempre provocará UnsupportedOperationException que se produzca. Sin embargo, si las claves o valores contenidos son mutables por sí mismas, esto puede hacer que el mapa se comporte incoherentemente o su contenido parezca cambiar. <li>No permiten null claves y valores. Los intentos de crearlos con null claves o valores dan como resultado NullPointerException. <li>Son serializables si todas las claves y valores son serializables. <li>Rechazan claves duplicadas en el momento de la creación. Las claves duplicadas pasadas a un método de generador estático dan como IllegalArgumentExceptionresultado . <li>El orden de iteración de las asignaciones no está especificado y está sujeto a cambios. <li>Son basados en valores. Los programadores deben tratar las instancias que son #equals(Object) iguales que intercambiables y no deben usarlas para la sincronización o puede producirse un comportamiento impredecible. Por ejemplo, en una versión futura, es posible que se produzca un error en la sincronización. Los autores de llamadas no deben suponer la identidad de las instancias devueltas. Las fábricas son gratuitas para crear nuevas instancias o reutilizar las existentes. <li>Se serializan como se especifican en la página Formulario serializado . </ul>

Esta interfaz es miembro del marco de colecciones de Java.

Agregado en la versión 1.2.

Java documentación para java.util.Map.

Las partes de esta página son modificaciones basadas en el trabajo creado y compartido por el Android y se usan según los términos descritos en creative Creative Commons 2.5 Attribution License.