IMap Interface

Définition

[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

Dérivé

Android.Util.ArrayMap

Java.Util.AbstractMap

Java.Util.Concurrent.ConcurrentHashMap

Java.Util.Concurrent.IConcurrentMap

Java.Util.EnumMap

Plus…

Attributs

RegisterAttribute JavaTypeParametersAttribute

Implémente

IJavaObject IJavaPeerable IDisposable

Remarques

Objet qui mappe les clés aux valeurs. Une carte ne peut pas contenir de clés en double ; chaque clé peut être mappée à une valeur au maximum.

Cette interface prend la place de la Dictionary classe, qui était une classe totalement abstraite plutôt qu’une interface.

L’interface Map fournit trois vues de collection, qui permettent d’afficher le contenu d’une carte en tant qu’ensemble de clés, de collection de valeurs ou d’ensemble de mappages clé-valeur. L’ordre d’une carte est défini comme l’ordre dans lequel les itérateurs des vues de collection de la carte retournent leurs éléments. Certaines implémentations de carte, comme la TreeMap classe, font des garanties spécifiques quant à leur ordre de rencontre ; d’autres, comme la HashMap classe, ne le font pas. Les mappages avec un ordre de rencontre défini sont généralement des sous-types de l’interface SequencedMap .

Remarque : un grand soin doit être exercé si des objets mutables sont utilisés comme clés de carte. Le comportement d’une carte n’est pas spécifié si la valeur d’un objet est modifiée d’une manière qui affecte les comparaisons equals pendant que l’objet est une clé dans la carte. Un cas particulier de cette interdiction est qu’il n’est pas permis à une carte de se contenir en tant que clé. Bien qu’il soit permis à une carte de se contenir comme valeur, la prudence extrême est conseillée : les equals méthodes ne hashCode sont plus bien définies sur une telle carte.

Toutes les classes d’implémentation de mappage à usage général doivent fournir deux constructeurs « standard » : un constructeur void (aucun argument) qui crée un mappage vide et un constructeur avec un seul argument de type Map, qui crée une carte avec les mêmes mappages clé-valeur que son argument. En effet, le dernier constructeur permet à l’utilisateur de copier n’importe quelle carte, produisant une carte équivalente de la classe souhaitée. Il n’existe aucun moyen d’appliquer cette recommandation (car les interfaces ne peuvent pas contenir de constructeurs), mais toutes les implémentations de mappage à usage général dans le JDK sont conformes.

Les méthodes « destructrices » contenues dans cette interface, autrement dit, les méthodes qui modifient la carte sur laquelle elles fonctionnent sont spécifiées pour lever UnsupportedOperationException si cette carte ne prend pas en charge l’opération. Si c’est le cas, ces méthodes peuvent, mais ne sont pas nécessaires, lever une UnsupportedOperationException exception si l’appel n’aurait aucun effet sur la carte. Par exemple, l’appel de la #putAll(Map) méthode sur une carte non modifiable peut, mais n’est pas nécessaire, lever l’exception si la carte dont les mappages doivent être « superposés » est vide.

Certaines implémentations de carte ont des restrictions sur les clés et les valeurs qu’elles peuvent contenir. Par exemple, certaines implémentations interdisent les clés et valeurs Null, et certaines ont des restrictions sur les types de leurs clés. La tentative d’insertion d’une clé ou d’une valeur non éligible lève une exception non cochée, généralement NullPointerException ou ClassCastException. La tentative d’interrogation de la présence d’une clé ou d’une valeur inéligible peut lever une exception, ou elle peut simplement retourner false ; certaines implémentations présenteront l’ancien comportement et certaines présenteront cette dernière. Plus généralement, la tentative d’une opération sur une clé ou une valeur inéligible dont l’achèvement n’entraînerait pas l’insertion d’un élément inéligible dans la carte peut lever une exception ou réussir, à l’option de l’implémentation. Ces exceptions sont marquées comme « facultatives » dans la spécification de cette interface.

De nombreuses méthodes dans les interfaces Collections Framework sont définies en termes de Object#equals(Object) equals méthode. Par exemple, la spécification de la #containsKey(Object) containsKey(Object key) méthode indique : « retourne true si et seulement si cette carte contient un mappage pour une clé k telle que (key==null ? k==null : key.equals(k))». Cette spécification ne doit pas être interprétée pour impliquer que l’appel Map.containsKey avec un argument key non null entraîne key.equals(k) l’appel d’une clé k. Les implémentations sont libres d’implémenter des optimisations dans lesquelles l’appel equals est évité, par exemple, en comparant d’abord les codes de hachage des deux clés. (La Object#hashCode() spécification garantit que deux objets avec des codes de hachage inégaux ne peuvent pas être égaux.) Plus généralement, les implémentations des différentes interfaces collections Framework sont libres de tirer parti du comportement spécifié des méthodes sous-jacentes Object où que l’implémenteur le juge approprié.

Certaines opérations cartographiques qui effectuent une traversée récursive de la carte peuvent échouer à l’exception des instances autoréférentielles où la carte contient directement ou indirectement elle-même. Cela inclut les méthodes et clone()equals()hashCode() les toString()méthodes. Les implémentations peuvent éventuellement gérer le scénario auto-référentielle, mais la plupart des implémentations actuelles ne le font pas.

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

Les Map#of() Map.ofméthodes de Map#ofEntries(Map.Entry...) Map.ofEntriesfabrique statique, et Map#copyOf Map.copyOf les méthodes de fabrique statiques offrent un moyen pratique de créer des cartes non modifiables. Les Map instances créées par ces méthodes ont les caractéristiques suivantes :

<ul>li Ils sont <inmodifiables></i>.<> Les clés et les valeurs ne peuvent pas être ajoutées, supprimées ou mises à jour. L’appel d’une méthode mutator sur la carte entraîne UnsupportedOperationException toujours la levée. Toutefois, si les clés ou valeurs contenues sont elles-mêmes mutables, cela peut entraîner le comportement incohérent de la carte ou de son contenu. <li>Ils interdisent les null clés et les valeurs. Les tentatives de création avec null des clés ou des valeurs aboutissent à NullPointerException. <li>Ils sont sérialisables si toutes les clés et valeurs sont sérialisables. <li>Ils rejettent les clés dupliquées au moment de la création. Les clés dupliquées passées à une méthode de fabrique statique aboutissent à IllegalArgumentException. <li>L’ordre d’itération des mappages n’est pas spécifié et est susceptible de changer. <li>Elles sont basées sur des valeurs. Les programmeurs doivent traiter les instances qui sont #equals(Object) égales comme interchangeables et ne doivent pas les utiliser pour la synchronisation ou un comportement imprévisible peut se produire. Par exemple, dans une version ultérieure, la synchronisation peut échouer. Les appelants ne doivent pas faire d’hypothèses sur l’identité des instances retournées. Les fabriques sont libres de créer de nouvelles instances ou de réutiliser des instances existantes. <li>Ils sont sérialisés comme spécifié dans la page Formulaire sérialisé. </ul>

Cette interface est membre de Java Collections Framework.

Ajouté dans la version 1.2.

Documentation Java pour java.util.Map.

Les parties de cette page sont des modifications basées sur le travail créé et partagé par le projet Android Open Source et utilisés en fonction des termes décrits dans la licence d’attribution Creative Commons 2.5.