.net - must - Uso de métodos de extensión
extension method must be defined in a non-generic static class (9)
¿Cuándo tiene sentido usar métodos de extensión?
Tienen sentido cuando está utilizando LINQ y desea encadenar o canalizar salida funcional de una función a otra. Mejora la legibilidad del código y le permite expresar un concepto de manera más elegante (lo que sea que valga la pena).
También le permiten dar la apariencia de métodos de instancia en cualquier tipo que desee sin modificar la fuente de ese tipo, esto a menudo puede ayudar a la legibilidad y la expresividad de su código cuando se usa razonablemente.
¿Agregar métodos de extensión a un tipo afecta el rendimiento?
Tenga en cuenta que un método de extensión llama como:
instance.SomeExtensionMethod()
se compila a:
StaticExtensionMethodClass.SomeExtensionMethod(instance);
por lo que el rendimiento será el mismo que cualquier otra llamada a método estático.
Estas preguntas son el seguimiento de la pregunta que hice antes sobre los Métodos de extensión .
Además de las otras respuestas, los métodos de extensión son una excelente manera de agregar la implementación de la placa de calderas a las interfaces. Por ejemplo, si desea que todas las listas se puedan ordenar, agregue un método de extensión para IList<T> .
Usted puede (como ya se dijo) también usar métodos de extensión para agregar métodos a clases fuera de su control; Alguna vez has querido un método Reverse() en una string ? ¡Agrega uno!
La única diferencia es que los métodos de extensión no usan virtual, y no hay verificación nula. Puede usar esto para su ventaja si lo desea:
public static void ThrowIfNull<T>(this T obj, string name) where T : class
{
if(obj == null) throw new ArgumentNullException(name);
}
A diferencia de los métodos de utilidad regulares, hacen que sea muy fácil escribir interfaces fluidas; esta es una de las razones de su existencia, es decir, con LINQ:
var foo = source.Where(predicate).OrderBy(selector);
es mucho más legible que:
var foo = Enumerable.OrderBy(Enumerable.Where(source,predicate),selector);
Con métodos regulares, para utilizar el primer enfoque, debería ser un método de instancia regular, que requeriría cambios (por ejemplo) a IEnumerable<T> - no deseable.
No estoy al tanto de ninguna implicancia en el rendimiento. El uso de métodos de extensión tiene más sentido cuando no tiene acceso al código fuente y, por lo tanto, no puede agregar el método a la clase directamente, y el método tiene sentido para implementarse como una función. Esto va al comentario que hice en su pregunta anterior, donde otra persona dio una muestra para un método de extensión en la clase ''cadena'' que devolvió un bool en función de si la cadena era un correo electrónico válido. Esto, IMO, es un ejemplo de cuándo NO usar un método de extensión, porque esa función no es fundamental para el tipo de cadena. Sin embargo, tiene sentido agregar una función izquierda (int) y una función derecha (int) a ''cadena''.
Otro uso interesante de los métodos de extensión es cuando le gustaría tener cierta funcionalidad agregada a una clase en un espacio de nombres pero no en otro. Un ejemplo específico es agregar métodos para facilitar las pruebas de unidades: no querría que abarroten sus ensamblajes de producción, pero son geniales cuando se realizan pruebas de unidades.
Se utilizó para extender (agregar) la funcionalidad de las clases existentes sin cambiarlas realmente.
Puede ver esto en cómo LINQ (System.Linq namespace y otros) agrega mucha funcionalidad a todas las colecciones.
Los métodos de extensión brillan allí donde se usa programación funcional.
Considere casi todas las funciones a nivel de módulo que ya tiene en su aplicación y en qué se convierten cuando las etiqueta como métodos de extensión. Se convierten en una oportunidad para "voz activa" sobre "voz pasiva". La voz activa significa que el código se lee como si una instancia proporcionara su propio método para realizar una tarea en particular, en lugar de hacer que la función realice una acción pasivamente sobre ella.
ExtendUnlimitedCredit(AddVIP(tblCustomer, "Bill Gates"))
vs.
tblCustomer.AddVIP("Bill Gates").ExtendUnlimitedCredit()
Los métodos de extensión simplifican esta transformación. La eliminación de llamadas a funciones anidadas con código de "voz activa" a menudo es una mejora. Además, dado que nuestra tienda bloquea sus clases principales, solo pudimos utilizar llamadas de función anidadas antes de los métodos de extensión.
Las otras cosas buenas acerca de los métodos de extensión:
Hacen que sus funciones (debido a Intellisense) sean más reconocibles. Y si proporcionó un marcado en línea que describe el propósito y el uso de su función, Intellisense incluso proporcionará una útil información sobre herramientas que describe el método y su uso para el desarrollador que lo descubre (simplemente presionando el punto). Las funciones que no están etiquetadas como métodos de extensión no se descubren tan fácilmente, pueden no usarse y, como resultado, alguien más puede inventar su propio sabor de dicha función.
Mientras que en realidad no se puede implementar un método para una interfaz, un método de extensión ofrece un medio alternativo que da la apariencia de que ya lo hizo.
Los uso para reutilizar mis clases de modelo de objetos. Tengo un montón de clases que representan objetos que tengo en una base de datos. Estas clases se usan solo en el lado del cliente para mostrar los objetos, por lo que el uso básico es acceder a las propiedades.
public class Stock {
public Code { get; private set; }
public Name { get; private set; }
}
Debido a ese patrón de uso, no quiero tener métodos de lógica de negocios en estas clases, por lo que hago que cada lógica comercial sea un método de extensión.
public static class StockExtender {
public static List <Quote> GetQuotesByDate(this Stock s, DateTime date)
{...}
}
De esta forma puedo usar las mismas clases para el procesamiento de lógica de negocios y para la visualización de la interfaz de usuario sin sobrecargar el lado del cliente con código innecesario.
Una cosa interesante acerca de esta solución es que mis clases de modelo de objetos se generan dinámicamente usando Mono.Cecil , por lo que sería muy difícil agregar métodos de lógica de negocios, incluso si quisiera. Tengo un compilador que lee archivos de definición XML y genera estas clases de stubs que representan algún objeto que tengo en la base de datos. El único enfoque en este caso es extenderlos.
Dirigiéndose a su segunda pregunta: mi regla de oro es que el método de extensión debe ser una "extensión natural de la funcionalidad" en el tipo o que debe ser una parte fácil de mantener y legible de una interfaz fluida.
Un ejemplo de una "extensión natural de la funcionalidad" es extender un lector de datos para devolver un valor predeterminado si se produce un emparejamiento de DBNull. No es tan natural extender el lector de datos para devolver una instancia de la entidad representada por los datos en múltiples campos. En este último caso, estás inyectando las responsabilidades incorrectas en el objeto pobre :).
De mi respuesta aquí :
Con respecto a un uso práctico para los Métodos de extensión, puede agregar nuevos métodos a una clase sin derivar una nueva clase.
Eche un vistazo al siguiente ejemplo:
public class extended {
public int sum() {
return 7+3+2;
}
}
public static class extending {
public static float average(this extended extnd) {
return extnd.sum() / 3;
}
}
Como puede ver, la clase Extending agrega un método denominado promedio a la clase Extended . Para obtener el promedio, llame al método average , ya que pertenece a la clase extended :
extended ex = new extended();
Console.WriteLine(ex.average());
Referencia: http://aspguy.wordpress.com/2008/07/03/a-practical-use-of-serialization-and-extension-methods-in-c-30/
En cuanto a rendimiento , creo que se puede ver una mejora con los métodos de extensión, ya que nunca se envían dinámicamente, pero todo depende de cómo se implemente el método dinámico.