ICollection Interface

Définition

[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

Dérivé

Android.Util.ArraySet

Java.Util.AbstractCollection

Java.Util.AbstractList

Java.Util.AbstractQueue

Java.Util.AbstractSet

Plus…

Attributs

RegisterAttribute JavaTypeParametersAttribute

Implémente

IJavaObject IJavaPeerable IIterable IDisposable

Remarques

Interface racine dans la hiérarchie de collection. Une collection représente un groupe d’objets, appelé ses éléments. Certaines collections autorisent les éléments en double et d’autres ne le font pas. Certains sont commandés et d’autres non ordonnés. Le JDK ne fournit aucune implémentation directe de cette interface : il fournit des implémentations de sous-interfaces plus spécifiques telles que Set et List. Cette interface est généralement utilisée pour transmettre des regroupements et les manipuler là où la généralité maximale est souhaitée.

Les sacs ou les multisets (collections non ordonnées qui peuvent contenir des éléments en double) doivent implémenter directement cette interface.

Toutes les classes d’implémentation à usage Collection général (qui implémentent Collection généralement indirectement l’une de ses sous-interfaces) doivent fournir deux constructeurs « standard » : un constructeur void (aucun argument), qui crée une collection vide et un constructeur avec un seul argument de type Collection, qui crée une collection avec les mêmes éléments que son argument. En effet, ce dernier constructeur permet à l’utilisateur de copier n’importe quelle collection, produisant une collection équivalente du type d’implémentation souhaité. Il n’existe aucun moyen d’appliquer cette convention (car les interfaces ne peuvent pas contenir de constructeurs), mais toutes les implémentations à usage Collection général dans les bibliothèques de plateforme Java sont conformes.

Certaines méthodes sont spécifiées comme facultatives. Si une implémentation de collection n’implémente pas d’opération particulière, elle doit définir la méthode correspondante à lever UnsupportedOperationException. Ces méthodes sont marquées « opération facultative » dans les spécifications de méthode des interfaces de collections.

« restrictions facultatives »> Certaines implémentations de collection ont des restrictions sur les éléments qu’ils peuvent contenir. Par exemple, certaines implémentations interdisent les éléments Null et certaines ont des restrictions sur les types de leurs éléments. La tentative d’ajout d’un élément inéligible lève une exception non cochée, généralement NullPointerException ou ClassCastException. La tentative d’interrogation de la présence d’un élément 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 un élément inéligible dont l’achèvement n’entraînerait pas l’insertion d’un élément inéligible dans la collection 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.

Il incombe à chaque collection de déterminer sa propre stratégie de synchronisation. En l’absence d’une garantie plus forte par l’implémentation, le comportement non défini peut résulter de l’appel d’une méthode sur une collection mutée par un autre thread ; cela inclut les appels directs, le passage de la collection à une méthode susceptible d’effectuer des appels et l’utilisation d’un itérateur existant pour examiner la collection.

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 #contains(Object) contains(Object o) méthode indique : « retourne true si et seulement si cette collection contient au moins un élément e tel que (o==null ? e==null : o.equals(e))». Cette spécification ne doit pas être interprétée pour impliquer que l’appel Collection.contains avec un argument o non null entraîne o.equals(e) l’appel d’un élément e. 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 éléments. (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 de collection qui effectuent une traversée récursive de la collection peuvent échouer à l’exception des instances autoréférentielles où la collection contient directement ou indirectement elle-même. Cela inclut les méthodes et hashCode()equals()toString() les clone()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>"view">View Collections</h2>

La plupart des collections gèrent le stockage des éléments qu’ils contiennent. En revanche, les collections d’affichage elles-mêmes ne stockent pas d’éléments, mais s’appuient plutôt sur une collection de stockage pour stocker les éléments réels. Les opérations qui ne sont pas gérées par la collection d’affichages proprement dite sont déléguées à la collection de stockage. Parmi les exemples de collections d’affichage, citons les collections wrapper retournées par des méthodes telles que Collections#checkedCollection Collections.checkedCollection, Collections#synchronizedCollection Collections.synchronizedCollectionet Collections#unmodifiableCollection Collections.unmodifiableCollection. D’autres exemples de collections de vues incluent des collections qui fournissent une représentation différente des mêmes éléments, par exemple, comme fourni par List#subList List.subList, NavigableSet#subSet NavigableSet.subSetou Map#entrySet Map.entrySet. Toutes les modifications apportées à la collection de stockage sont visibles dans la collection d’affichages. En conséquence, toutes les modifications apportées à la collection d’affichages &mdash ; si les modifications sont autorisées &mdash ; sont écrits dans la collection de stockage. Bien qu’elles ne soient pas techniquesment des collections, les instances et IteratorListIterator peuvent également permettre l’écriture de modifications dans la collection de stockage, et dans certains cas, les modifications apportées à la collection de stockage seront visibles par l’itérateur pendant l’itération.

<h2>"unmodifiable">Unmodifiable Collections</h2>

Certaines méthodes de cette interface sont considérées comme « destructrices » et sont appelées méthodes « mutator » dans lesquelles elles modifient le groupe d’objets contenus dans la collection sur laquelle ils opèrent. Ils peuvent être spécifiés pour lever UnsupportedOperationException si cette implémentation de collection ne prend pas en charge l’opération. Ces méthodes doivent (mais ne sont pas nécessaires) lever une UnsupportedOperationException exception si l’appel n’aurait aucun effet sur la collection. Par exemple, considérez une collection qui ne prend pas en charge l’opération #add add . Que se passe-t-il si la #addAll addAll méthode est appelée sur cette collection, avec une collection vide comme argument ? L’ajout d’éléments zéro n’a aucun effet. Il est donc permis pour cette collection simplement de ne rien faire et de ne pas lever d’exception. Toutefois, il est recommandé que de tels cas lèvent une exception sans condition, car la levée uniquement dans certains cas peut entraîner des erreurs de programmation.

Une collection non modifiable est une collection, dont toutes les méthodes mutator (telles que définies ci-dessus) sont spécifiées pour lever UnsupportedOperationException. Une telle collection ne peut donc pas être modifiée en appelant des méthodes dessus. Pour qu’une collection soit correctement non modifiable, toutes les collections d’affichage dérivées de celle-ci doivent également être non modifiables. Par exemple, si une liste n’est pas modifiable, la liste retournée par List#subList List.subList est également non modifiable.

Une collection non modifiable n’est pas nécessairement immuable. Si les éléments contenus sont mutables, l’ensemble de la collection est clairement mutable, même s’il peut être inmodifiable. Par exemple, considérez deux listes non modifiables contenant des éléments mutables. Le résultat de l’appel list1.equals(list2) peut différer d’un appel à l’autre si les éléments avaient été mutés, même si les deux listes ne sont pas modifiables. Toutefois, si une collection non modifiable contient tous les éléments immuables, elle peut être considérée comme immuable efficacement.

<h2>"unmodview">Unmodifiable View Collections</h2>

Une collection d’affichages non modifiable est une collection qui n’est pas modifiable et qui est également une vue sur une collection de stockage. Ses méthodes de mutateur lèvent UnsupportedOperationException, comme décrit ci-dessus, lors de la lecture et de l’interrogation des méthodes sont déléguées à la collection de stockage. L’effet est de fournir un accès en lecture seule à la collection de stockage. Cela est utile pour qu’un composant fournisse aux utilisateurs un accès en lecture à une collection interne, tout en les empêchant de modifier de telles collections de manière inattendue. Les exemples de collections d’affichages non modifiables sont ceux retournés par les méthodes associées et les Collections#unmodifiableCollection Collections.unmodifiableCollectionCollections#unmodifiableList Collections.unmodifiableListméthodes associées.

Notez que les modifications apportées à la collection de stockage peuvent toujours être possibles et, si elles se produisent, elles sont visibles par le biais de la vue non modifiable. Ainsi, une collection d’affichages non modifiables n’est pas nécessairement immuable. Toutefois, si la collection de stockage d’une vue non modifiable est effectivement immuable, ou si la seule référence à la collection de stockage est via une vue non modifiable, la vue peut être considérée comme immuable efficacement.

<h2>"serializable">Serializability of Collections</h2>

La sérialisation des collections est facultative. Par conséquent, aucune des interfaces de collections n’est déclarée pour implémenter l’interface java.io.Serializable . Toutefois, la sérialisabilité est considérée comme étant généralement utile, la plupart des implémentations de collection sont sérialisables.

Les implémentations de collection qui sont des classes publiques (telles que ArrayList ou HashMap) sont déclarées pour implémenter l’interface Serializable s’ils sont en fait sérialisables. Certaines implémentations de collections ne sont pas des classes publiques, telles que les collections non modifiables. Dans ce cas, la sérialisation de ces collections est décrite dans la spécification de la méthode qui les crée, ou dans un autre endroit approprié. Dans les cas où la sérialisation d’une collection n’est pas spécifiée, il n’existe aucune garantie quant à la sérialisation de ces collections. En particulier, de nombreuses collections d’affichages ne sont pas sérialisables.

Une implémentation de collection qui implémente l’interface Serializable ne peut pas être garantie comme sérialisable. En général, les collections contiennent des éléments d’autres types et il n’est pas possible de déterminer statiquement si les instances d’un type d’élément sont réellement sérialisables. Par exemple, considérez un sérialisable Collection<E>, où E n’implémente pas l’interface Serializable . La collection peut être sérialisable, s’il contient uniquement des éléments d’un sous-type sérialisable de E, ou s’il est vide. Les collections sont donc considérées comme sérialisables de manière conditionnelle, car la sérialisation de la collection dans son ensemble dépend de la sérialisable ou non de la collection elle-même et du fait que tous les éléments contenus sont également sérialisables.

Un cas supplémentaire se produit avec des instances de SortedSet et SortedMap. Ces collections peuvent être créées avec une Comparator commande qui impose un classement sur les éléments définis ou les clés cartographiques. Une telle collection est sérialisable uniquement si l’élément fourni Comparator est également sérialisable.

Cette interface est membre de Java Collections Framework.

Ajouté dans la version 1.2.

Documentation Java pour java.util.Collection.

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.

Propriétés

Méthodes

Implémentations d’interfaces explicites

Méthodes d’extension

S’applique à