ICollection Schnittstelle
Definition
Wichtig
Einige Informationen beziehen sich auf Vorabversionen, die vor dem Release ggf. grundlegend überarbeitet werden. Microsoft übernimmt hinsichtlich der hier bereitgestellten Informationen keine Gewährleistungen, seien sie ausdrücklich oder konkludent.
Die Stammschnittstelle in der Sammlungshierarchie.
[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- Abgeleitet
- Attribute
- Implementiert
Hinweise
Die Stammschnittstelle in der Sammlungshierarchie. Eine Auflistung stellt eine Gruppe von Objekten dar, die als elemente bezeichnet wird. Einige Sammlungen ermöglichen doppelte Elemente und andere nicht. Einige sind sortiert und andere ungeordnet. Der JDK stellt keine direkten Implementierungen dieser Schnittstelle bereit: Er stellt Implementierungen speziellerer Unterinterfaces wie Set und List. Diese Schnittstelle wird in der Regel verwendet, um Sammlungen zu übergeben und sie zu bearbeiten, wo die maximale Generalität gewünscht wird.
Taschen oder Multisets (ungeordnete Auflistungen , die doppelte Elemente enthalten können) sollten diese Schnittstelle direkt implementieren.
Alle allgemeinen Implementierungsklassen (die in der Regel indirekt über eine seiner Unterinterfaces implementiert Collection werden) sollten zwei "Standard"-CollectionKonstruktoren bereitstellen: einen leeren Konstruktor (keine Argumente), der eine leere Auflistung erstellt, und ein Konstruktor mit einem einzigen Argument vom TypCollection, wodurch eine neue Auflistung mit denselben Elementen wie das Argument erstellt wird. Der letztere Konstruktor ermöglicht es dem Benutzer, jede Sammlung zu kopieren, wodurch eine entsprechende Auflistung des gewünschten Implementierungstyps erzeugt wird. Es gibt keine Möglichkeit, diese Konvention zu erzwingen (da Schnittstellen keine Konstruktoren enthalten können), aber alle allgemeinen Implementierungen in den Java-Plattformbibliotheken Collection entsprechen.
Bestimmte Methoden werden als optional angegeben. Wenn eine Sammlungsimplementierung keinen bestimmten Vorgang implementiert, sollte sie die entsprechende Methode definieren, die ausgelöst UnsupportedOperationExceptionwerden soll. Solche Methoden sind in Methodenspezifikationen der Auflistungsschnittstellen als "optionaler Vorgang" gekennzeichnet.
"optional-restrictions">Einige Sammlungsimplementierungen haben Einschränkungen für die Elemente, die sie enthalten können. Einige Implementierungen verbieten z. B. NULL-Elemente, und einige haben Einschränkungen für die Typen ihrer Elemente. Wenn Sie versuchen, ein nicht berechtigtes Element hinzuzufügen, wird eine deaktivierte Ausnahme ausgelöst, in der Regel NullPointerException oder ClassCastException. Wenn Sie versuchen, das Vorhandensein eines nicht zulässigen Elements 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 ein nicht zulässiges Element, dessen Abschluss nicht dazu führen würde, dass ein nicht berechtigtes Element in die Auflistung 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.
Es liegt an jeder Sammlung, um eine eigene Synchronisierungsrichtlinie zu bestimmen. Wenn keine stärkere Garantie durch die Implementierung besteht, kann das nicht definierte Verhalten dazu führen, dass eine Methode für eine Sammlung aufgerufen wird, die von einem anderen Thread stumm geschaltet wird; Dies umfasst direkte Aufrufe, das Übergeben der Auflistung an eine Methode, die Aufrufe ausführen kann, und die Verwendung eines vorhandenen Iterators zum Untersuchen der Auflistung.
Viele Methoden in Collections Framework-Schnittstellen werden in Bezug auf die Object#equals(Object) equals Methode definiert. Die Spezifikation für die #contains(Object) contains(Object o) Methode besagt beispielsweise: "Gibt nur dann zurück true , wenn diese Auflistung mindestens ein Element e enthält, (o==null ? e==null : o.equals(e))das so ist." Diese Spezifikation sollte nicht so ausgelegt werden, dass das Aufrufen Collection.contains mit einem Argument ungleich Null oo.equals(e) für jedes Element eaufgerufen wird. Implementierungen sind frei, Optimierungen zu implementieren, bei denen der equals Aufruf vermieden wird, z. B. indem zuerst die Hashcodes der beiden Elemente 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 Auflistungsvorgänge, die rekursive Traversal der Auflistung ausführen, können mit einer Ausnahme für selbstreferentielle Instanzen fehlschlagen, in denen sich die Auflistung direkt oder indirekt befindet. 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>"view"View Collections<>/h2>
Die meisten Sammlungen verwalten Speicher für elemente, die sie enthalten. Im Gegensatz dazu speichern Sammlungen selbst keine Elemente, sondern verlassen sich auf eine sicherungsnde Sammlung, um die tatsächlichen Elemente zu speichern. Vorgänge, die nicht von der Ansichtsauflistung selbst behandelt werden, werden an die Sicherungsauflistung delegiert. Beispiele für Ansichtssammlungen sind die Wrapperauflistungen, die von Methoden wie Collections#checkedCollection Collections.checkedCollection, , Collections#synchronizedCollection Collections.synchronizedCollectionund Collections#unmodifiableCollection Collections.unmodifiableCollection. Weitere Beispiele für Ansichtssammlungen sind Sammlungen, die eine andere Darstellung der gleichen Elemente bereitstellen, z. B. wie von List#subList List.subList, , NavigableSet#subSet NavigableSet.subSetoder Map#entrySet Map.entrySet. Alle An der Sicherungsauflistung vorgenommenen Änderungen sind in der Ansichtssammlung sichtbar. Entsprechende Änderungen an der Ansichtssammlung — wenn Änderungen zulässig sind — werden in die Sicherungssammlung geschrieben. Obwohl sie technisch keine Auflistungen sind, können Instanzen von Iterator und ListIterator auch zulassen, dass Änderungen in die Sicherungsauflistung geschrieben werden, und in einigen Fällen sind Änderungen an der Sicherungsauflistung während der Iteration für den Iterator sichtbar.
<h2>"unmodifiable">Unmodifiable Collections</h2>
Bestimmte Methoden dieser Schnittstelle gelten als "destruktiv" und werden als "Mutator"-Methoden bezeichnet, in denen sie die Gruppe von Objekten ändern, die in der Auflistung enthalten sind, auf der sie arbeiten. Sie können angegeben werden, um auszuwerfen, wenn diese Sammlungsimplementierung UnsupportedOperationException den Vorgang nicht unterstützt. Solche Methoden sollten (aber nicht erforderlich) einen UnsupportedOperationException Auslösen, wenn der Aufruf keine Auswirkungen auf die Sammlung hätte. Betrachten Sie beispielsweise eine Auflistung, die den #add add Vorgang nicht unterstützt. Was geschieht, wenn die #addAll addAll Methode für diese Auflistung mit einer leeren Auflistung als Argument aufgerufen wird? Das Hinzufügen von Nullelementen hat keine Wirkung, daher ist es zulässig, dass diese Sammlung einfach nichts tut und keine Ausnahme auslöst. Es wird jedoch empfohlen, eine Ausnahme bedingungslos auszuwerfen, da das Auslösen nur in bestimmten Fällen zu Programmierfehlern führen kann.
Eine unveränderliche Auflistung ist eine Auflistung, deren Mutatormethoden (wie oben definiert) zum Auslösen UnsupportedOperationExceptionangegeben werden. Eine solche Sammlung kann daher nicht durch Aufrufen von Methoden geändert werden. Damit eine Auflistung ordnungsgemäß nicht veränderbar ist, müssen alle darin abgeleiteten Ansichtsauflistungen ebenfalls nicht modifizierbar sein. Wenn z. B. eine Liste nicht veränderbar ist, ist die von List#subList List.subList ihnen zurückgegebene Liste ebenfalls nicht modifizierbar.
Eine unveränderliche Sammlung ist nicht notwendigerweise unveränderlich. Wenn die enthaltenen Elemente änderbar sind, ist die gesamte Sammlung deutlich änderbar, obwohl sie möglicherweise nicht veränderbar ist. Betrachten Sie beispielsweise zwei nicht veränderbare Listen mit veränderbaren Elementen. Das Ergebnis des Anrufs list1.equals(list2) kann sich von einem Aufruf zum nächsten unterscheiden, wenn die Elemente stumm geschaltet wurden, auch wenn beide Listen nicht veränderbar sind. Wenn eine nicht modifizierbare Auflistung jedoch alle unveränderlichen Elemente enthält, kann sie als effektiv unveränderlich betrachtet werden.
<h2>"unmodview">Unmodifiable View Collections</h2>
Eine nicht modifizierbare Ansichtssammlung ist eine Sammlung, die nicht modifizierbar ist und auch eine Ansicht auf einer sicherungsfähigen Auflistung ist. Die Mutatormethoden werden ausgelöst UnsupportedOperationException, wie oben beschrieben, während Lese- und Abfragemethoden an die Sicherungsauflistung delegiert werden. Der Effekt besteht darin, schreibgeschützten Zugriff auf die Sicherungsauflistung bereitzustellen. Dies ist nützlich für eine Komponente, um Benutzern Lesezugriff auf eine interne Sammlung zu gewähren, während sie verhindern, dass diese Sammlungen unerwartet geändert werden. Beispiele für nicht veränderbare Ansichtssammlungen sind diejenigen, die von den Collections#unmodifiableCollection Collections.unmodifiableCollectionMethoden , Collections#unmodifiableList Collections.unmodifiableListund verwandten Methoden zurückgegeben werden.
Beachten Sie, dass Änderungen an der Sicherungsauflistung möglicherweise immer noch möglich sind, und wenn sie auftreten, sind sie in der nicht modifizierbaren Ansicht sichtbar. Daher ist eine unveränderliche Ansichtssammlung nicht notwendigerweise unveränderlich. Wenn die Sicherungsauflistung einer nicht modifizierbaren Ansicht jedoch effektiv unveränderlich ist oder der einzige Verweis auf die Sicherungssammlung über eine nicht modifizierbare Ansicht erfolgt, kann die Ansicht als effektiv unveränderlich angesehen werden.
<h2>"serializable">Serializability of Collections</h2>
Die Serialisierbarkeit von Sammlungen ist optional. Daher werden keine der Auflistungsschnittstellen deklariert, um die java.io.Serializable Schnittstelle zu implementieren. Die Serialisierbarkeit gilt jedoch als allgemein nützlich, sodass die meisten Sammlungsimplementierungen serialisierbar sind.
Die Sammlungsimplementierungen, die öffentliche Klassen (z ArrayList . B. oder HashMap) sind, werden deklariert, um die Serializable Schnittstelle zu implementieren, wenn sie tatsächlich serialisierbar sind. Einige Auflistungsimplementierungen sind keine öffentlichen Klassen, z. B. die nicht modifizierbaren Auflistungen. In solchen Fällen wird die Serialisierung solcher Sammlungen in der Spezifikation der Methode beschrieben, die sie erstellt, oder an einem anderen geeigneten Ort. In Fällen, in denen die Serialisierbarkeit einer Sammlung nicht angegeben ist, gibt es keine Garantie für die Serialisierbarkeit solcher Sammlungen. Insbesondere sind viele Ansichtssammlungen nicht serialisierbar.
Eine Sammlungsimplementierung, die die Serializable Schnittstelle implementiert, kann nicht garantiert werden, dass sie serialisierbar ist. Der Grund dafür ist, dass Auflistungen elemente anderer Typen enthalten, und es ist nicht möglich, statisch zu bestimmen, ob Instanzen eines Bestimmten Elementtyps tatsächlich serialisierbar sind. Betrachten Sie z. B. eine serialisierbare Collection<E>Schnittstelle, bei der E die Serializable Schnittstelle nicht implementiert wird. Die Auflistung kann serialisierbar sein, wenn sie nur Elemente eines serialisierbaren Untertyps enthält Eoder leer ist. Sammlungen sind daher bedingt serialisierbar, da die Serialisierbarkeit der Sammlung insgesamt davon abhängt, ob die Sammlung selbst serialisierbar ist und ob alle enthaltenen Elemente ebenfalls serialisierbar sind.
Ein weiterer Fall tritt mit Instanzen von SortedSet und SortedMap. Diese Auflistungen können mit einer Comparator Auflistung erstellt werden, die eine Sortierung für die festgelegten Elemente oder Kartenschlüssel aufzwingt. Eine solche Sammlung ist nur serialisierbar, wenn die bereitgestellte Comparator auch serialisierbar ist.
Diese Schnittstelle ist ein Mitglied des Java Collections Framework.
In 1.2 hinzugefügt.
Java-Dokumentation für java.util.Collection.
Teile dieser Seite sind Änderungen auf der Grundlage von Arbeiten, die vom Android Open Source-Projekt erstellt und freigegeben werden und gemäß den in der Creative Commons 2.5 Attribution License beschriebenen Begriffen verwendet werden.
Eigenschaften
| Handle |
Ruft den JNI-Wert des zugrunde liegenden Android-Objekts ab. (Geerbt von IJavaObject) |
| IsEmpty |
Gibt zurück, wenn dies |
| JniIdentityHashCode |
Gibt den Wert |
| JniManagedPeerState |
Status des verwalteten Peers. (Geerbt von IJavaPeerable) |
| JniPeerMembers |
Mitgliedszugriff und Aufrufunterstützung. (Geerbt von IJavaPeerable) |
| PeerReference |
Gibt eine JniObjectReference der umbrochenen Java-Objektinstanz zurück. (Geerbt von IJavaPeerable) |
Methoden
| Add(Object) |
Stellt sicher, dass diese Auflistung das angegebene Element (optionaler Vorgang) enthält. |
| AddAll(ICollection) |
Fügt alle Elemente in der angegebenen Auflistung dieser Auflistung hinzu (optionaler Vorgang). |
| Clear() |
Entfernt alle Elemente aus dieser Auflistung (optionaler Vorgang). |
| Contains(Object) |
Gibt zurück |
| ContainsAll(ICollection) |
Gibt zurück |
| Disposed() |
Wird aufgerufen, wenn die Instanz verworfen wurde. (Geerbt von IJavaPeerable) |
| DisposeUnlessReferenced() |
Wenn keine offenen Verweise auf diese Instanz vorhanden sind, wird nichts aufgerufen |
| Equals(Object) |
Vergleicht das angegebene Objekt mit dieser Auflistung für die Gleichheit. |
| Finalized() |
Wird aufgerufen, wenn die Instanz abgeschlossen wurde. (Geerbt von IJavaPeerable) |
| ForEach(IConsumer) |
Führt die angegebene Aktion für jedes Element der |
| GetHashCode() |
Gibt den Hashcodewert für diese Auflistung zurück. |
| Iterator() |
Gibt einen Iterator für die Elemente in dieser Auflistung zurück. |
| Remove(Object) |
Entfernt eine einzelne Instanz des angegebenen Elements aus dieser Auflistung, wenn es vorhanden ist (optionaler Vorgang). |
| RemoveAll(ICollection) |
Entfernt alle Elemente dieser Auflistung, die auch in der angegebenen Auflistung enthalten sind (optionaler Vorgang). |
| RemoveIf(IPredicate) |
Entfernt alle Elemente dieser Auflistung, die das angegebene Prädikat erfüllen. |
| RetainAll(ICollection) |
Behält nur die Elemente in dieser Auflistung bei, die in der angegebenen Auflistung enthalten sind (optionaler Vorgang). |
| SetJniIdentityHashCode(Int32) |
Legen Sie den von |
| SetJniManagedPeerState(JniManagedPeerStates) |
Die Stammschnittstelle in der Sammlungshierarchie. (Geerbt von IJavaPeerable) |
| SetPeerReference(JniObjectReference) |
Legen Sie den von |
| Size() |
Gibt die Anzahl der Elemente in dieser Auflistung zurück. |
| Spliterator() |
Erstellt eine |
| ToArray() |
Gibt ein Array zurück, das alle Elemente in dieser Auflistung enthält. |
| ToArray(IIntFunction) |
Gibt ein Array zurück, das alle Elemente in dieser Auflistung enthält, wobei die bereitgestellte |
| ToArray(Object[]) |
Gibt ein Array zurück, das alle Elemente in dieser Auflistung enthält; Der Laufzeittyp des zurückgegebenen Arrays ist die des angegebenen Arrays. |
| UnregisterFromRuntime() |
Heben Sie die Registrierung dieser Instanz auf, damit die Laufzeit sie nicht aus zukünftigen Java.Interop.JniRuntime+JniValueManager.PeekValue Aufrufen zurückgibt. (Geerbt von IJavaPeerable) |
Explizite Schnittstellenimplementierungen
| IIterable.Spliterator() |
Erstellt eine |
Erweiterungsmethoden
| JavaCast<TResult>(IJavaObject) |
Führt eine android-laufzeitgecheckte Typkonvertierung aus. |
| JavaCast<TResult>(IJavaObject) |
Die Stammschnittstelle in der Sammlungshierarchie. |
| GetJniTypeName(IJavaPeerable) |
Die Stammschnittstelle in der Sammlungshierarchie. |
| ToEnumerable(IIterable) |
Die Stammschnittstelle in der Sammlungshierarchie. |
| ToEnumerable<T>(IIterable) |
Die Stammschnittstelle in der Sammlungshierarchie. |