¿Por qué se guardó GetEnumerator() en una interfaz separada de IEnumerator?

Question

Me preguntaba por qué el método GetEnumerator() se excluyó de IEnumerator y se colocó en IEnumerable. Me parece que tendría más sentido mantener todos los métodos del enumerador en IEnumerator.

Gracias,

de Scott

Answer 1

Pregúntate a ti mismo "imagina si esto fuera cierto".

Si todos los métodos de enumeración estuvieran en una única interfaz, ¿cómo podrían dos usuarios enumerar la misma lista al mismo tiempo?

Hay dos interfaces porque una dice: "Puede enumerarme", mientras que la otra dice: "aquí hay un objeto que realiza un seguimiento de una tarea de enumeración determinada".

La interfaz IEnumerable es una fábrica que crea tantos objetos IEnumerator como desee. Cómo y cuándo se utilizan esos enumeradores depende del consumidor.

Answer 2

IEnumerable implica que el objeto es una colección o fuente de datos que pueden ser iterado sobre de una forma lineal. IEnumerator es la interfaz para la implementación real que realiza la iteración.

Answer 3

Porque "IEnumerable" dice "ven, enumerame" (y luego dices -cómo, dame el Enumerador), sin embargo, "IEnumerator" dice "puedo enumerar tu colección". y ya lo tienes, no necesitas obtener más.

Answer 4

Porque a menudo lo que hace la enumeración es solo tangencial (si es que lo está) relacionado con lo enumerado. Si IEnumerable e IEnumerator eran la misma interfaz, no podrían compartirse, o tendría que tener algún argumento sin tipo en GetEnumerator que le permitiera pasar el objeto para ser enumerado. Dividirlos permite que la infraestructura de enumeración se comparta potencialmente entre diferentes tipos.

Answer 5

Tienes muy buenas respuestas aquí. Solo un poco de énfasis. Un enumerador mantiene el estado, realiza un seguimiento del objeto actual en la colección que se enumera. Disponible a través de IEnumerator.Current. Y sabe cómo cambiar ese estado, IEnumerator.MoveNext(). Mantener el estado requiere un objeto separado que almacene el estado. Ese estado no se puede almacenar dentro del objeto de colección fácilmente porque solo hay un objeto de colección, pero puede haber más de un enumerador.

Utilicé la frase "fácilmente" porque en realidad es posible que una colección realice un seguimiento de sus enumeradores. Después de todo, era una llamada al método GetEnumerator() de la clase de recopilación que devolvía el iterador. Hay una clase de colección en el marco .NET que hace esto, Microsoft.VisualBasic.Collection. Necesitaba implementar un contrato VB6 para su clase Collection y ese contrato especifica que el cambio de una colección mientras se está enumerando es legal. Lo que significa que cuando se modifique la Colección, debe ser razonable con todos los objetos del iterador que se crearon.

Se les ocurrió un truco muy bueno, WeakReference podría haberse inspirado en esto. Echa un vistazo al código mostrado por Reflector. Cosas inspiradoras Cave un poco más y encuentre "versión" en las clases de colección. Truco impresionante

Answer 6

Después de leer la publicación de Bart De Smet en minlinq Ya no estoy de acuerdo con que sea estrictamente necesario dividir las dos interfaces.

Por ejemplo - en el siguiente enlace, IEnumerable/IEnumerator se collaped a una única interfaz de método

Func<Func<Option<T>>> 

y algunas implementaciones básicas

public static class FEnumerable 
{ 
    public static Func<Func<Option<T>>> Empty<T>() 
    { 
     return() =>() => new Option<T>.None(); 
    } 

    public static Func<Func<Option<T>>> Return<T>(T value) 
    { 
     return() => 
     { 
      int i = 0; 
      return() => 
       i++ == 0 
       ? (Option<T>)new Option<T>.Some(value) 
       : (Option<T>)new Option<T>.None(); 
     }; 
    } 

    ... 

} 

public static Func<Func<Option<T>>> Where<T>(this Func<Func<Option<T>>> source, Func<T, bool> filter) 
{ 
    return source.Bind(t => filter(t) ? FEnumerable.Return(t) : FEnumerable.Empty<T>()); 
}