Resharper sugiere que el parámetro puede ser del tipo ‘BaseType’

¿Cuáles son los beneficios de usar tipos base en parámetros de método?

Aquí hay una muestra:

private void Foo(List numbers) //R# laments: parameter can be IEnumerable. { foreach (var i in numbers) { Console.WriteLine(i); } } 

Y aquí hay otra.

 public class Foo : ICloneable { public object Clone() { return MemberwiseClone(); } public Foo CopyMe(Foo other) //R# laments: parameter can be ICloneable { return (Foo)other.Clone(); } } 

… donde podemos cambiar el tipo y cualquier cosa, pero Foo fallará en el tiempo de ejecución.

Entonces, la pregunta: ¿qué debo hacer cuando R # sugiere que el parámetro puede ser del tipo ‘X’ ?


PD. Solo otra explicación para Whysharper – un plugin que encaja con Resharper y StackOverflow . La gente dice que es agradable, pero que carece de buenas explicaciones; esperamos que juntos podamos mejorarlo;).

El uso de tipos de base para parámetros tiene los siguientes beneficios:

  • Reduce el acoplamiento innecesario en su código
  • Hace que su código sea más flexible al permitir un rango más amplio de entradas válidas
  • Hace que su código sea más seguro al limitar los tipos de operaciones que se pueden realizar en la entrada
  • Mejora el rendimiento de su código al reducir la necesidad de realizar conversiones entre tipos

Sin embargo, no siempre debe usar un tipo base en una llamada de método solo porque una herramienta como ReSharper dice que es posible. Debe asegurarse de que el uso y la semántica de los métodos sean claros, y que es probable que los cambios futuros no requieran bajar la jerarquía de herencia, lo que podría romper el código existente.

En los ejemplos anteriores, el uso de IEnumerable en lugar de la Lista hace posible que las personas que llaman a su código pasen no solo los objetos de la Lista, sino también las matrices, stacks, colas e incluso los resultados de las llamadas LINQ (que principalmente devuelven IEnumerable). Ya que su código solo itera sobre la colección, no necesita saber acerca de la Lista. También significa que los consumidores de su código no tendrán que convertir sus colecciones en copias de tipo Lista solo para pasarlas a su método.

Es el principio de sustitución de Liskov.