Hay algunas preguntas similares a esta que se ocupan de los tipos de entrada y salida correctos.Me gusta esto. Mi pregunta es más sobre la práctica correcta, la denominación de métodos, la elección del tipo de parámetro, la protección contra accidentes, etc.a raíz deLinq.

Linq casi en todas partes se ocupa deIEnumerable y eso no es todo, pero también introduce algo extraño anosotros llamadoEjecución diferida. Es posible que nos hayamos equivocado al diseñar nuestros métodos (especialmente los métodos de extensión) cuando pensamos que la mejor idea es tomar el tipo más básico. Así que nuestros métodos parecían:

public static IEnumerable<T> Shuffle<T>(this IEnumerable<T> lstObject)
{
    foreach (T t in lstObject)
       //some fisher-yates may be
}

El peligro, obviamente, es cuando mezclamos la función anterior con la perezosa.Linq y estan susceptible

var query = foos.Select(p => p).Where(p => p).OrderBy(p => p); //doesn't execute
//but
var query = foos.Select(p => p).Where(p => p).Shuffle().OrderBy(p => p);
//the second line executes up to a point.

Una gran edición aquí:

Para aclarar la línea anterior - Mi pregunta no es sobre la segunda expresión que no se evalúa, en serio no. Los programadores lo saben. Mi preocupacion es acerca deShuffle Método realmente ejecutando la consulta hasta ese punto. Ver la primera consulta, donde nada se ejecuta. Ahora, de manera similar, al construir otra expresión Linq (que debería ejecutarse más adelante), nuestra función personalizada es jugar al deporte de spoils. En otras palabras, cómo avisar a la persona que llama.Shuffle no es la función de tipo que desearían en ese punto de la expresión Linq. Espero que el punto sea llevado a casa. Disculpas :) Aunque es tan simple como ir e inspeccionar el método, estoy preguntando cómo suelen programar defensivamente ...

El ejemplo anterior puede no ser tan peligroso, pero entiendes el punto. Es cierto que las funciones (personalizadas) no van bien con elLinq Idea de ejecución diferida. El problema no es solo el rendimiento, sino también los efectos secundarios inesperados.

Pero una función como esta funciona con la magia.Linq:

public static IEnumerable<S> DistinctBy<S, T>(this IEnumerable<S> source, 
                                              Func<S, T> keySelector)
{
    HashSet<T> seenKeys = new HashSet<T>(); //credits Jon Skeet
    foreach (var element in source)
        if (seenKeys.Add(keySelector(element)))
            yield return element;
}

Como puedes ver las dos funciones tomanIEnumerable<>, pero la persona que llama no sabría cómo reaccionan las funciones. ¿Cuáles son las medidas generales de precaución que ustedes toman aquí?

Nombra nuestros métodos personalizados de manera adecuada para que a la persona que llama se le dé la idea de que funciona bien o no conLinq?

Movimientoperezoso métodos a un espacio de nombres diferente, y mantenerLinq-¿Así que a otro, para que le dé algún tipo de idea al menos?

No aceptes unIEnumerable como parámetro paraimmediately ejecutando métodos, pero en lugar de eso, tome un tipo más derivado o un tipo concreto en sí mismo que, por lo tanto, dejaIEnumerable por métodos perezosos solo? ¿Esto supone una carga para la persona que llama hacer la ejecución de posibles expresiones no ejecutadas? Esto es bastante posible para nosotros, ya que fuera.Linq mundo con el que apenas nos enfrentamosIEnumerables, y la mayoría de las clases de colección básica implementan hastaICollection al menos.

¿O algo más? Me gusta particularmente la tercera opción, y eso es con lo que iba, pero pensé en obtener sus ideas antes. He visto un montón de código (bonito pocoLinq como métodos de extensión!) incluso de buenos programadores que aceptanIEnumerable y hacer unToList() O algo similar en ellos dentro del método. No sé cómo lidiar con los efectos secundarios ..

Editar: Después de un voto a la baja y una respuesta, me gustaría aclarar que no se trata de que los programadores no sepan cómo funciona Linq (nuestra competencia podría ser en algún nivel, pero eso es una cosa diferente), pero es que muchas funciones se escribieron sin llevar a Linq a Cuenta entonces. Ahora, encadenar un método de ejecución inmediata junto con los métodos de extensión Linq lo hacen peligroso. Entonces, mi pregunta es si hay una guía general que los programadores siguen para que la persona que llama sepa qué usar del lado de Linq y qué no.¡Se trata más de programar a la defensiva que si usted no sabe cómo usarlo, entonces no podemos ayudarlo! (o al menos creo) ..