IMap Schnittstelle

Definition

[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

Abgeleitet

Android.Util.ArrayMap

Java.Util.AbstractMap

Java.Util.Concurrent.ConcurrentHashMap

Java.Util.Concurrent.IConcurrentMap

Java.Util.EnumMap

Mehr…

Attribute

RegisterAttribute JavaTypeParametersAttribute

Implementiert

IJavaObject IJavaPeerable IDisposable

Hinweise

Ein Objekt, das Schlüssel zu Werten zuordnet. Eine Karte darf keine doppelten Schlüssel enthalten; jeder Schlüssel kann höchstens einem Wert zugeordnet werden.

Diese Schnittstelle findet statt der Dictionary Klasse statt einer Schnittstelle statt einer Schnittstelle statt einer völlig abstrakten Klasse statt statt der Klasse statt.

Die Map Schnittstelle stellt drei Sammlungsansichten bereit, mit denen der Inhalt einer Karte als Eine Reihe von Schlüsseln, Sammlung von Werten oder Satz von Schlüsselwertzuordnungen angezeigt werden kann. Die Reihenfolge einer Karte wird als Die Reihenfolge definiert, in der die Iteratoren in den Auflistungsansichten der Karte ihre Elemente zurückgeben. Einige Kartenimplementierungen, z. B. die TreeMap Klasse, stellen spezifische Garantien für ihre Begegnungsreihenfolge dar; andere, wie die HashMap Klasse, nicht. Karten mit einer definierten Begegnungsreihenfolge sind im Allgemeinen Untertypen der SequencedMap Schnittstelle.

Hinweis: Große Sorgfalt muss ausgeübt werden, wenn veränderbare Objekte als Kartenschlüssel verwendet werden. Das Verhalten einer Karte wird nicht angegeben, wenn der Wert eines Objekts auf eine Weise geändert wird, die sich auf Vergleiche auswirkt equals , während das Objekt ein Schlüssel in der Karte ist. Ein Sonderfall dieses Verbots besteht darin, dass eine Karte nicht als Schlüssel zulässig ist. Obwohl es zulässig ist, dass eine Karte sich selbst als Wert enthält, wird äußerste Vorsicht empfohlen: Die equals Methoden hashCode sind auf einer solchen Karte nicht mehr gut definiert.

Alle allgemeinen Zuordnungsimplementierungsklassen sollten zwei "Standard"-Konstruktoren bereitstellen: einen void -Konstruktor (keine Argumente), der eine leere Zuordnung erstellt, und ein Konstruktor mit einem einzigen Argument vom Typ Map, wodurch eine neue Zuordnung mit denselben Schlüsselwertzuordnungen wie das Argument erstellt wird. Der letztere Konstruktor ermöglicht es dem Benutzer, eine beliebige Karte zu kopieren und eine entsprechende Zuordnung der gewünschten Klasse zu erzeugen. Es gibt keine Möglichkeit, diese Empfehlung zu erzwingen (da Schnittstellen keine Konstruktoren enthalten können), aber alle allgemeinen Zuordnungsimplementierungen im JDK entsprechen.

Die in dieser Schnittstelle enthaltenen "destruktiven" Methoden, d. h. die Methoden, die die Karte ändern, auf der sie ausgeführt werden, werden angegeben, um auszuwerfen UnsupportedOperationException , wenn diese Karte den Vorgang nicht unterstützt. Wenn dies der Fall ist, können diese Methoden, aber nicht erforderlich, einen UnsupportedOperationException Auslösen auslösen, wenn der Aufruf keine Auswirkungen auf die Karte hätte. Das Aufrufen der #putAll(Map) Methode auf einer nicht modifizierbaren Karte kann z. B. die Ausnahme auslösen, wenn die Karte, deren Zuordnungen "überlagert" sein sollen, leer ist.

Einige Kartenimplementierungen haben Einschränkungen für die Schlüssel und Werte, die sie enthalten können. Einige Implementierungen verbieten z. B. NULL-Schlüssel und -Werte, und einige haben Einschränkungen für die Typen ihrer Schlüssel. Beim Versuch, einen nicht förderbaren Schlüssel oder Wert einzufügen, wird eine nicht aktivierte Ausnahme ausgelöst, in der Regel NullPointerException oder ClassCastException. Wenn Sie versuchen, das Vorhandensein eines nicht zulässigen Schlüssels oder Werts abzufragen, wird möglicherweise eine Ausnahme ausgelöst, oder sie gibt einfach "false" zurück. einige Implementierungen zeigen das frühere Verhalten und einige zeigen letztere. Im Allgemeinen kann der Versuch eines Vorgangs für einen nicht zulässigen Schlüssel oder Wert, dessen Abschluss nicht dazu führen würde, dass ein nicht berechtigtes Element in die Karte eingefügt wird, eine Ausnahme auslösen, oder es kann erfolgreich sein, wenn die Implementierung möglich ist. Solche Ausnahmen werden in der Spezifikation für diese Schnittstelle als "optional" gekennzeichnet.

Viele Methoden in Collections Framework-Schnittstellen werden in Bezug auf die Object#equals(Object) equals Methode definiert. Die Spezifikation für die #containsKey(Object) containsKey(Object key) Methode lautet beispielsweise: "Gibt nur dann zurück true , wenn diese Karte eine Zuordnung für einen Schlüssel k enthält, (key==null ? k==null : key.equals(k))sodass " Diese Spezifikation sollte nicht so ausgelegt werden, dass das Aufrufen Map.containsKey mit einem Argument ungleich Null key für einen Schlüssel kaufgerufen wirdkey.equals(k). Implementierungen sind frei, Optimierungen zu implementieren, bei denen der equals Aufruf vermieden wird, z. B. indem zuerst die Hashcodes der beiden Schlüssel verglichen werden. (Die Object#hashCode() Spezifikation garantiert, dass zwei Objekte mit ungleichen Hashcodes nicht gleich sein können.) Im Allgemeinen sind Implementierungen der verschiedenen Collections Framework-Schnittstellen frei, um das angegebene Verhalten zugrunde Object liegender Methoden zu nutzen, unabhängig davon, wo der Implementor sie als angemessen erachtet.

Einige Zuordnungsvorgänge, die rekursive Durchquerungen der Karte ausführen, können mit einer Ausnahme für selbstreferentielle Instanzen fehlschlagen, in denen sich die Zuordnung direkt oder indirekt selbst enthält. Dies schließt die clone()Methoden hashCode()equals()und Methoden toString() ein. Implementierungen können optional das selbstreferentielle Szenario behandeln, die meisten aktuellen Implementierungen tun dies jedoch nicht.

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

Die Map#of() Map.ofMethoden , Map#ofEntries(Map.Entry...) Map.ofEntriesund Map#copyOf Map.copyOf statische Factory bieten eine bequeme Möglichkeit zum Erstellen unveränderlicher Karten. Die Map von diesen Methoden erstellten Instanzen weisen die folgenden Merkmale auf:

<ul><li>Sie sind <i>unmodififiable</i>. Schlüssel und Werte können nicht hinzugefügt, entfernt oder aktualisiert werden. Das Aufrufen einer Mutatormethode auf der Karte führt UnsupportedOperationException immer dazu, dass sie ausgelöst wird. Wenn jedoch die enthaltenen Schlüssel oder Werte selbst änderbar sind, kann dies dazu führen, dass sich die Karte inkonsistent verhält oder der Inhalt sich ändert. <li>Sie verbieten null Schlüssel und Werte. Versuche, sie mit null Schlüsseln oder Werten zu erstellen, führen zu NullPointerException. <li>Sie sind serialisierbar, wenn alle Schlüssel und Werte serialisierbar sind. <li>Sie lehnen doppelte Schlüssel zur Erstellungszeit ab. Doppelte Schlüssel, die an eine statische Factorymethode übergeben werden, führen zu IllegalArgumentException. <li>Die Iterationsreihenfolge von Zuordnungen ist nicht angegeben und kann geändert werden. <li>Sie sind wertbasiert. Programmierer sollten Instanzen behandeln, die #equals(Object) gleich austauschbar sind und diese nicht für die Synchronisierung verwenden sollten, oder unvorhersehbares Verhalten auftreten kann. In einer zukünftigen Version kann die Synchronisierung z. B. fehlschlagen. Aufrufer sollten keine Annahmen über die Identität der zurückgegebenen Instanzen treffen. Fabriken können neue Instanzen erstellen oder vorhandene wiederverwenden. <li>Sie werden wie auf der Serialisierten Formularseite serialisiert . </ul>

Diese Schnittstelle ist ein Mitglied des Java Collections Framework.

In 1.2 hinzugefügt.

Java Dokumentation für java.util.Map.

Teile dieser Seite sind Änderungen auf der Grundlage von Arbeiten, die von der Android Open Source Project erstellt und gemeinsam verwendet und gemäß den in der 2.5 Attribution License beschriebenen Begriffen verwendet werden.