una método metodos metodo llamar invocar genérica funciones extensión estática ejemplos definirse debe clases clase c# .net design design-patterns extension-methods

método - metodos y funciones en c#



Métodos de extensión frente a la clase de utilidad estática (3)

Estoy buscando algunos pros y contras para usar métodos de extensión sobre clases de utilidad estática en una aplicación C #.

Por ejemplo, una ventaja en la columna de métodos de extensión es la conveniencia de llamar por el nombre de la clase en lugar de algo como "StringUtils". Pero una estafa sería que puede difuminar las líneas entre lo que está en el marco y lo que no.


Al final del día, ambos enfoques utilizan métodos estáticos. La única diferencia entre

string foo = "bob"; StringUtils.DoSomething(foo);

y

string foo = "bob"; foo.DoSomething();

es azúcar sintáctico. Se reduce a preferencias personales y estándares de codificación. A veces, el nombre del método puede ser lo suficientemente descriptivo como para no garantizar que se vea el nombre de la clase estática. Otras veces tiene más sentido incluir el nombre de la clase.

¡Finalmente, los métodos de extensión también pueden invocarse como métodos estáticos!

string foo = "bob"; StringExtensions.DoSomething(foo);

Lo anterior usa el mismo código que en el segundo ejemplo, pero se invoca de manera diferente. Con este último tidbit en mente, podría crear clases de utilidad estáticas como métodos de extensión y luego invocarlas como lo desee.


Diría que un profesional es que borra las líneas entre lo que está en el marco y lo que no: puede usar su propio código de forma tan natural como el código de marco, operando en tipos de marcos.

Los métodos de extensión no deben usarse arbitrariamente, por supuesto, no todos los métodos estáticos deben convertirse en métodos de extensión.

Intento pensar en ello como si el método lógicamente funciona "en" su primer parámetro. ¿Tendría sentido como método de instancia si pudieras incluirlo como método de instancia?

Una "estafa" de la que puede no estar enterado: si el tipo ampliado más tarde agrega un método de instancia del mismo nombre que es aplicable con los mismos parámetros, su código de llamada comenzará a llamar de manera transparente ese método de instancia la próxima vez que recompile. Por ejemplo, Stream ganó CopyTo en .NET 4 ... Anteriormente había escrito un método de extensión CopyTo , que luego no se llamaría. No hay advertencia de que esto está ocurriendo, por lo que debe estar alerta.

Una advertencia: los métodos de extensión no han existido durante el tiempo suficiente para que las mejores prácticas realmente se establezcan. Debería sopesar todas las opiniones (incluso, o quizás especialmente, las mías) cuidadosamente.


Personalmente me gusta la legibilidad y las llamadas en cadena (implícitamente proporciona legibilidad) proporcionadas por los métodos de extensión.

1) Readability: bool empty = String.IsNullOrEmpty (myString) //in comparison to bool empty = myString.IsNullOrEmpty (); 2) Chain calls: var query = Enumerable.Range(0, 10) .Where(x => x % 2 == 0) .Reverse(); //instead of var query = Enumerable.Reverse(Enumerable.Where(Enumerable.Range(0, 10), x => x % 2 == 0));

Con su método de extensión puede ser anulado por miembro de la instancia si accidentalmente lo hace. Personalmente, no me gusta esto. Al menos el compilador debería haber gritado, si está sucediendo en el mismo ensamblado.