c# ienumerable ilist icollection custom-collection

c# - Colección personalizada utilizando IEnumerable vs ICollection vs IList



custom-collection (3)

En primer lugar, no tiene que elegir realmente entre estas interfaces, si es necesario puede implementar las tres. En segundo lugar, la implementación de IEnumerable no requiere que haga pública la lista subyacente. Puede implementar solo los métodos para utilizar el enumerador de la lista subyacente.

En lo que respecta al rendimiento, dudo que haya un gran impacto, concéntrese en lo que necesita funcionalmente. La única manera de saber con certeza es medir.

Necesito diseñar mi propia clase personalizada GenericCollection . Ahora tengo muchas opciones para derivarlo usando IEnumerable , ICollection e IList , donde más adelante se ofrecen algunas funcionalidades adicionales.

Estoy un poco confundido de que si voy con IEnumerable<T> podría requerir declarar que el objeto realmente mantenga la colección como en este caso _list .

public class GenericCollection<T> : IEnumerable<T> { private List<T> _list; //... }

Pero si voy con ICollection<T> o IList<T> , no necesito declarar el objeto List ya que está implícitamente disponible.

public class GenericCollection<T> : IList<T> { // no need for List object //private List<T> _list; //... }

¿Cuál es la diferencia entre estos dos enfoques con respecto al rendimiento ?

En qué escenario se prefiere cada uno, especialmente cuando se trata de diseñar su propia colección. Estoy interesado en la colección de peso ligero con buen rendimiento. Creo que esto se puede lograr usando IEnumerable<T> pero, ¿qué hay de las razones para hacerlo?

He revisado algunas publicaciones existentes pero ninguna da la información requerida.

Devolviendo ''IList'' vs ''ICollection'' vs ''Colección''


Es poco probable que el rendimiento dependa de qué interfaces se implementan. Depende más bien de cuántas instrucciones deba ejecutar el procesador para lograr un determinado objetivo. Si implementa IEnumerable y envuelve la Lista, es probable que termine escribiendo los métodos Agregar / Eliminar / [] que solo propagan las llamadas a la Lista, lo que agregaría una sobrecarga de rendimiento. Por lo tanto, aunque no tomé ninguna medida, el enfoque de herencia probablemente sería un poco más rápido.

Sin embargo, estos detalles generalmente solo son importantes para las aplicaciones en tiempo real con una necesidad extrema de guardar todos los ciclos de CPU posibles. Eric Lippert tiene un excelente artículo sobre cómo prestar atención a tales detalles: http://blogs.msdn.com/b/ericlippert/archive/2003/10/17/53237.aspx . En general, es probable que esté mejor utilizando el enfoque que mejor se adapte a la lógica de negocios y la arquitectura de su aplicación, en lugar de los detalles de rendimiento.


IEnumerable , ICollection e IList (en general, cualquier tipo con un prefijo I ) son solo interfaces . Le permiten exponer lo que hará su clase, pero a diferencia de si inherit una clase, las interfaces no le proporcionan una implementación predeterminada de ninguna de las cosas que dicen que debe hacer.

En cuanto a elegir qué interfaz, aquí hay una guía rápida:

  • Un IList es un ICollection que se puede acceder por índice.
  • Una IEnumerable es una IEnumerable con fácil acceso a elementos como Add , Remove y Count .
  • Un IEnumerable es cualquier cosa que se pueda enumerar, incluso si la lista de esas cosas no existe hasta que la enumeras.

Algunas clases que podría desear extender (o mantener como un campo privado que ejecuta la mayor parte de la lógica) para su colección son List<T> , Collection<T> , (que implementa IList<T> , pero con un acceso más fácil para anular) implementación, vea Colección <T> versus Lista <T> ¿qué debería usar en sus interfaces? para las grandes diferencias entre estos dos) ObservableCollection<T> , o colecciones que no son listas, como Dictionary<T, U> y HashSet<T> . Para obtener más información sobre cualquiera de estos, busque la documentación de MSDN en la clase.