Por que não .NET tem uma estrutura de dados Set?

Question

Um dos meus maiores problemas lidando com um movimento de Java para .Net é o fato de que não há uma interface Set em .Net. Eu sei que existem bibliotecas que eu poderia ir e download, mas o que é a razão para não tê-lo construído em? Há Maps (dicionário) e listas, mas por que não um Set?

Editar : Devo esclarecer que nem todo mundo usa Net 3.5 ainda - por isso estou mais ou menos referindo-se a versões mais antigas do .Net

Answer 1

Eu acho que é simplesmente uma omissão pelos escritores BCL. NET 3.5 tem um href="http://msdn.microsoft.com/en-us/library/bb359438.aspx" rel="nofollow noreferrer"> HashSet classe ; para versões anteriores, eu recomendo envolvendo um dicionário , com nulos no campo de valor, a O replicar (1) adicionar, remover e tempo de pesquisa.

Answer 2

Em .NET HashSet 4.0 vai ser adaptado até mesmo implementar nova interface ISet.

Answer 3

.NET 3.5 tem HashSet que faz todas as operações de conjunto.

Answer 4

Você quer dizer um HashSet ?

Answer 5

Há HashSet<T> nos dias de hoje, mas infelizmente nenhuma interface da qual eu estou ciente.

Answer 6

Como outros já mencionado, há uma HashSet<T>, que na verdade é apenas um conjunto.

A razão que tem "haxixe" na frente dele (um detalhe de implementação do conjunto, uma vez que usa hashes para eliminar duplicatas) é becase Set é uma palavra-chave em VB.NET.

Answer 7

Talvez o raciocínio é que um conjunto é realmente apenas uma lista com um detalhe de implementação especial que restringe os itens nele para ser distinto. Desde a distinção da lista é na implementação em vez da interface, não é necessária uma interface.

Como já foi mencionado, o FCL tem a HashSet<T> .

Answer 8

Eu também mudou de Java para .Net recentemente (devido ao emprego profissional) e devo admitir que meus problemas iniciais foram também em coleções.
Na versão .Net atual (3.5 e falando sobre C #), você deve orientar-se em

• ICollection
• IList<T>
• List<T>
• IDictionary<TKey,TValue>
• IEnumerable<T>

Estes são os mais comumente utilizados (esperança que eu não perca um)

Answer 9

Talvez por causa de considerações de ensino.

Um programador típico vê um conjuntos como um recipiente mágico que simplesmente funciona, não importa quantos elementos estão na mesma.

Se não houver um conjunto explícito, um programador é forçado a escolher outros tipos e ao fazê-lo refletir sobre os elementos contar e estrutura de dados adequada para alcançar um bom desempenho.

Apenas um palpite.