ICollection Interface
Definição
Importante
Algumas informações se referem a produtos de pré-lançamento que podem ser substancialmente modificados antes do lançamento. A Microsoft não oferece garantias, expressas ou implícitas, das informações aqui fornecidas.
A interface raiz na hierarquia de coleção.
[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- Derivado
- Atributos
- Implementações
Comentários
A interface raiz na hierarquia de coleção. Uma coleção representa um grupo de objetos, conhecidos como seus elementos. Algumas coleções permitem elementos duplicados e outras não. Alguns são ordenados e outros não ordenados. O JDK não fornece implementações diretas dessa interface: ele fornece implementações de subinterfaces mais específicas, como Set e List. Essa interface é normalmente usada para passar coleções e manipulá-las onde a generalidade máxima é desejada.
Sacos ou multisets (coleções não ordenadas que podem conter elementos duplicados) devem implementar essa interface diretamente.
Todas as classes de implementação de propósito Collection geral (que normalmente são implementadas Collection indiretamente por meio de uma de suas subinterfaces) devem fornecer dois construtores "padrão": um construtor void (sem argumentos), que cria uma coleção vazia, e um construtor com um único argumento do tipo Collection, que cria uma nova coleção com os mesmos elementos que seu argumento. Com efeito, o último construtor permite que o usuário copie qualquer coleção, produzindo uma coleção equivalente do tipo de implementação desejado. Não há como impor essa convenção (pois as interfaces não podem conter construtores), mas todas as implementações de propósito Collection geral nas bibliotecas da plataforma Java estão em conformidade.
Certos métodos são especificados para serem opcionais. Se uma implementação de coleção não implementar uma operação específica, ela deverá definir o método correspondente para lançar UnsupportedOperationException. Tais métodos são marcados como "operação opcional" nas especificações dos métodos das interfaces de coleta.
"Restrições opcionais">Algumas implementações de coleção têm restrições sobre os elementos que podem conter. Por exemplo, algumas implementações proíbem elementos nulos e algumas têm restrições sobre os tipos de seus elementos. A tentativa de adicionar um elemento inelegível gera uma exceção não verificada, normalmente NullPointerException ou ClassCastException. A tentativa de consultar a presença de um elemento inelegível pode lançar uma exceção, ou pode simplesmente retornar false; algumas implementações exibirão o primeiro comportamento e outras exibirão o segundo. De um modo mais geral, tentar uma operação sobre um elemento não elegível cuja conclusão não resultaria na inserção de um elemento não elegível na coleção pode lançar uma exceção ou pode ser bem-sucedida, à opção da implementação. Tais exceções são marcadas como "opcionais" na especificação para esta interface.
Cabe a cada coleção determinar sua própria política de sincronização. Na ausência de uma garantia mais forte pela implementação, o comportamento indefinido pode resultar da invocação de qualquer método em uma coleção que está sendo mutada por outro thread; Isso inclui chamadas diretas, passando a coleção para um método que pode executar chamadas e usando um iterador existente para examinar a coleção.
Muitos métodos nas interfaces do Collections Framework são definidos em termos do Object#equals(Object) equals método. Por exemplo, a especificação do #contains(Object) contains(Object o) método diz: "retorna true se e somente se esta coleção contiver pelo menos um elemento e tal que (o==null ? e==null : o.equals(e))". Essa especificação não deve ser interpretada como implicando que invocar Collection.contains com um argumento o não nulo fará com o.equals(e) que seja invocado para qualquer elemento e. As implementações são livres para implementar otimizações em que a equals invocação é evitada, por exemplo, comparando primeiro os códigos hash dos dois elementos. (A Object#hashCode() especificação garante que dois objetos com códigos hash desiguais não podem ser iguais.) De forma mais geral, as implementações das várias interfaces do Collections Framework são livres para aproveitar o comportamento especificado dos métodos subjacentes Object onde quer que o implementador considere apropriado.
Algumas operações de coleta que executam a travessia recursiva da coleção podem falhar, com exceção de instâncias autorreferenciais em que a coleção direta ou indiretamente contém a si mesma. Isso inclui o , equals()hashCode() e toString() métodosclone(). As implementações podem, opcionalmente, lidar com o cenário autorreferencial, no entanto, a maioria das implementações atuais não o faz.
<h2>"view">Ver coleções</h2>
A maioria das coleções gerencia o armazenamento dos elementos que elas contêm. Por outro lado, as coleções de exibição em si não armazenam elementos, mas dependem de uma coleção de suporte para armazenar os elementos reais. As operações que não são manipuladas pela própria coleção de exibição são delegadas à coleção de suporte. Exemplos de coleções de exibição incluem as coleções wrapper retornadas por métodos como Collections#checkedCollection Collections.checkedCollection, Collections#synchronizedCollection Collections.synchronizedCollectione Collections#unmodifiableCollection Collections.unmodifiableCollection. Outros exemplos de coleções de exibição incluem coleções que fornecem uma representação diferente dos mesmos elementos, por exemplo, conforme fornecido por List#subList List.subList, NavigableSet#subSet NavigableSet.subSetou Map#entrySet Map.entrySet. Quaisquer alterações feitas na coleção de backup são visíveis na coleção de exibição. Correspondentemente, quaisquer alterações feitas na coleção de exibição — se as alterações são permitidas — são gravados até a coleção de apoio. Embora tecnicamente não sejam coleções, instâncias de e ListIterator também podem permitir que modificações sejam gravadas na coleção de suporte e, em alguns casos, as modificações na coleção de Iterator suporte serão visíveis para o Iterator durante a iteração.
<h2>"unmodifiable">Coleções< não modificáveis/h2>
Certos métodos dessa interface são considerados "destrutivos" e são chamados de métodos "mutadores" na medida em que modificam o grupo de objetos contidos na coleção em que operam. Eles podem ser especificados para serem lançados UnsupportedOperationException se essa implementação de coleta não oferecer suporte à operação. Tais métodos devem (mas não são obrigados a) lançar um UnsupportedOperationException se a invocação não tiver efeito sobre a coleção. Por exemplo, considere uma coleção que não ofereça suporte à #add add operação. O que acontecerá se o #addAll addAll método for chamado nesta coleção, com uma coleção vazia como argumento? A adição de zero elementos não tem efeito, por isso é permitido que esta coleção simplesmente não faça nada e não lance uma exceção. No entanto, recomenda-se que tais casos lancem uma exceção incondicionalmente, pois lançar apenas em certos casos pode levar a erros de programação.
Uma coleção não modificável é uma coleção, cujos métodos mutadores (conforme definido acima) são especificados para lançar UnsupportedOperationException. Tal coleção, portanto, não pode ser modificada chamando-lhe quaisquer métodos. Para que uma coleção seja corretamente não modificável, todas as coleções de exibição derivadas dela também devem ser não modificáveis. Por exemplo, se uma Lista não for modificável, a Lista retornada por List#subList List.subList também não será modificável.
Uma coleção não modificável não é necessariamente imutável. Se os elementos contidos são mutáveis, toda a coleção é claramente mutável, mesmo que possa ser não modificável. Por exemplo, considere duas listas não modificáveis contendo elementos mutáveis. O resultado da chamada list1.equals(list2) pode ser diferente de uma chamada para a próxima se os elementos tiverem sido mutados, mesmo que ambas as listas não sejam modificáveis. No entanto, se uma coleção não modificável contiver todos os elementos imutáveis, ela poderá ser considerada efetivamente imutável.
<h2>"unmodview">Coleções< de exibição não modificáveis/h2>
Uma coleção de exibição não modificável é uma coleção que não pode ser modificada e que também é uma exibição em uma coleção de backup. Seus métodos mutadores lançam UnsupportedOperationException, conforme descrito acima, enquanto os métodos de leitura e consulta são delegados à coleção de suporte. O efeito é fornecer acesso somente leitura à coleção de suporte. Isso é útil para que um componente forneça aos usuários acesso de leitura a uma coleção interna, impedindo-os de modificar essas coleções inesperadamente. Exemplos de coleções de exibição não modificáveis são aquelas retornadas pelos Collections#unmodifiableCollection Collections.unmodifiableCollectionmétodos , Collections#unmodifiableList Collections.unmodifiableListe relacionados.
Observe que as alterações na coleção de backup ainda podem ser possíveis e, se ocorrerem, ficarão visíveis por meio do modo de exibição não modificável. Assim, uma coleção de exibição não modificável não é necessariamente imutável. No entanto, se a coleção de suporte de um modo de exibição não modificável for efetivamente imutável, ou se a única referência à coleção de backup for por meio de um modo de exibição não modificável, o modo de exibição poderá ser considerado efetivamente imutável.
<h2>"serializable">Serializabilidade de coleções</h2>
A serializabilidade de coleções é opcional. Como tal, nenhuma das interfaces de coleções são declaradas para implementar a java.io.Serializable interface. No entanto, a serializabilidade é considerada como sendo geralmente útil, portanto, a maioria das implementações de coleção são serializáveis.
As implementações de coleção que são classes públicas (como ArrayList ou HashMap) são declaradas para implementar a Serializable interface se elas forem de fato serializáveis. Algumas implementações de coleções não são classes públicas, como as coleções não modificáveis. Nesses casos, a serializabilidade de tais coleções é descrita na especificação do método que as cria, ou em algum outro local adequado. Nos casos em que a serializabilidade de uma coleção não é especificada, não há garantia sobre a serializabilidade de tais coleções. Em particular, muitas coleções de exibição não são serializáveis.
Não é possível garantir que uma implementação de coleção que implementa a Serializable interface seja serializável. O motivo é que, em geral, as coleções contêm elementos de outros tipos, e não é possível determinar estaticamente se instâncias de algum tipo de elemento são realmente serializáveis. Por exemplo, considere um serializável Collection<E>, onde E não implementa a Serializable interface. A coleção pode ser serializável, se contiver apenas elementos de algum subtipo serializável de E, ou se estiver vazia. As coleções são, portanto, ditas condicionalmente serializáveis, pois a serializabilidade da coleção como um todo depende se a coleção em si é serializável e se todos os elementos contidos também são serializáveis.
Um caso adicional ocorre com instâncias de SortedSet e SortedMap. Essas coleções podem ser criadas com um Comparator que impõe uma ordem nos elementos definidos ou chaves de mapa. Essa coleção é serializável somente se o fornecido Comparator também for serializável.
Essa interface é membro do Java Collections Framework.
Adicionado em 1.2.
Documentação Java para java.util.Collection.
Partes desta página são modificações baseadas no trabalho criado e compartilhado pelo Android Open Source Project e usado de acordo com os termos descritos na Creative Commons 2.5 Attribution License.
Propriedades
| Handle |
Obtém o valor JNI do objeto Android subjacente. (Herdado de IJavaObject) |
| IsEmpty |
Retorna se isso |
| JniIdentityHashCode |
Retorna o valor de |
| JniManagedPeerState |
Estado do par gerenciado. (Herdado de IJavaPeerable) |
| JniPeerMembers |
Acesso de membros e suporte à invocação. (Herdado de IJavaPeerable) |
| PeerReference |
Retorna uma JniObjectReference das instâncias do objeto Java encapsulado. (Herdado de IJavaPeerable) |
Métodos
| Add(Object) |
Garante que essa coleção contenha o elemento especificado (operação opcional). |
| AddAll(ICollection) |
Adiciona todos os elementos na coleção especificada a essa coleção (operação opcional). |
| Clear() |
Remove todos os elementos desta coleção (operação opcional). |
| Contains(Object) |
Retorna |
| ContainsAll(ICollection) |
Retorna |
| Disposed() |
Chamado quando a instância tiver sido descartada. (Herdado de IJavaPeerable) |
| DisposeUnlessReferenced() |
Se não houver referências pendentes a este caso, então chame |
| Equals(Object) |
Compara o objeto especificado com esta coleção para igualdade. |
| Finalized() |
Chamado quando a instância tiver sido finalizada. (Herdado de IJavaPeerable) |
| ForEach(IConsumer) |
Executa a ação fornecida para cada elemento do |
| GetHashCode() |
Retorna o valor do código hash para esta coleção. |
| Iterator() |
Retorna um iterador sobre os elementos nesta coleção. |
| Remove(Object) |
Remove uma única instância do elemento especificado dessa coleção, se ela estiver presente (operação opcional). |
| RemoveAll(ICollection) |
Remove todos os elementos desta coleção que também estão contidos na coleção especificada (operação opcional). |
| RemoveIf(IPredicate) |
Remove todos os elementos desta coleção que satisfazem o predicado fornecido. |
| RetainAll(ICollection) |
Retém apenas os elementos nesta coleção que estão contidos na coleção especificada (operação opcional). |
| SetJniIdentityHashCode(Int32) |
Defina o valor retornado por |
| SetJniManagedPeerState(JniManagedPeerStates) |
A interface raiz na hierarquia de coleção. (Herdado de IJavaPeerable) |
| SetPeerReference(JniObjectReference) |
Defina o valor retornado por |
| Size() |
Retorna o número de elementos nesta coleção. |
| Spliterator() |
Cria um |
| ToArray() |
Retorna uma matriz que contém todos os elementos desta coleção. |
| ToArray(IIntFunction) |
Retorna uma matriz que contém todos os elementos nesta coleção, usando a função fornecida |
| ToArray(Object[]) |
Retorna uma matriz contendo todos os elementos nesta coleção; O tipo de tempo de execução da matriz retornada é o da matriz especificada. |
| UnregisterFromRuntime() |
Cancele o registro dessa instância para que o tempo de execução não a retorne de chamadas futuras Java.Interop.JniRuntime+JniValueManager.PeekValue . (Herdado de IJavaPeerable) |
Implantações explícitas de interface
| IIterable.Spliterator() |
Cria um |
Métodos de Extensão
| JavaCast<TResult>(IJavaObject) |
Executa uma conversão de tipo verificada em tempo de execução do Android. |
| JavaCast<TResult>(IJavaObject) |
A interface raiz na hierarquia de coleção. |
| GetJniTypeName(IJavaPeerable) |
A interface raiz na hierarquia de coleção. |
| ToEnumerable(IIterable) |
A interface raiz na hierarquia de coleção. |
| ToEnumerable<T>(IIterable) |
A interface raiz na hierarquia de coleção. |