¿Cuáles son las mejores prácticas para usar los Métodos de extensión en .Net?

Question

He visto que se usan de todas formas, y se me ha acusado de usarlos de forma incorrecta (aunque en ese caso, los estaba usando de esa manera para demostrar point).

¿Cuáles cree que son las mejores prácticas para emplear los Métodos de extensión?

¿Los equipos de desarrollo deben crear una biblioteca de métodos de extensión y desplegarlos en varios proyectos?

¿Debería haber una colección de métodos de extensión comunes en la forma de un proyecto de código abierto?

Actualización: han decidido crear una amplia biblioteca de métodos de extensión organización

Answer 1

Creo que depende de con qué propósito los métodos de extensión sirven.

• Los métodos de extensión que se relacionan con las necesidades de negocio específicas de un proyecto (si están conectados a los tipos de datos básicos u objetos personalizados) no deben ser incluidos en una biblioteca que se distribuye a través de múltiples proyectos.
• Los métodos de extensión que se relacionan con los tipos de datos básicos (int, cadena, etc.) o los genéricos que tienen una aplicación más amplia podrían empaquetarse y distribuirse entre proyectos.

Tenga cuidado de no incluir globalmente los métodos de extensión que tienen poca aplicación, ya que simplemente obstruyen intellisense y pueden generar confusión y/o uso incorrecto.

Answer 2

He estado incluyendo mis métodos de extensión en mis bibliotecas Core en la clase Utils porque las personas que trabajan con mi framework probablemente encuentren los métodos útiles, pero para implementación masiva donde el desarrollador final podría tener la opción de bibliotecas de métodos de extensión, aconsejaría poner todos sus extensiones en su propio espacio de nombres, incluso su propio archivo de proyecto, por lo que la gente puede optar por añadir una referencia o una instrucción using o, simplemente, cuando sea necesario, así:

Core.Extensions.Base64Encode(str); 

La clase My Utils es mi mejor amigo en todo el mundo, fue antes de que llegaran los métodos de extensión y solo han ayudado a fortalecer nuestra relación. La regla más importante a la que recurriría es darle a la gente la opción de elegir el marco de extensión que están utilizando, siempre que sea posible.

Answer 3

es posible que desee echar un vistazo a http://www.codeplex.com/nxl y http://www.codeplex.com/umbrella que son ambas bibliotecas de métodos de extensión. Personalmente, no he echado un vistazo al código fuente, pero estoy seguro de que los muchachos de allí podrían darte algunos buenos consejos.

Answer 4

El lenguaje Objective-C ha tenido "Categorías" desde principios de la década de 1990; estos son esencialmente lo mismo que los métodos de extensión .NET. Al buscar las mejores prácticas, es posible que desee ver qué reglas generales los desarrolladores de Objective-C (Cocoa & NeXT) han encontrado a su alrededor.

Brent Simmons (el autor del lector RSS NetNewsWire para Mac OS X y iPhone) acaba de publicar hoy sobre su new style rules for the use of categories y que ha habido un poco de discussion in the Cocoa community alrededor de ese puesto.

Answer 5

El próximo lanzamiento de las Directrices de diseño de la estructura, segunda edición contará con una guía para la implementación de métodos de extensión, pero en general:

Sólo debe definir los métodos de extensión "donde hacen sentido semántico" y están proporcionando la función auxiliar relevante para cada implementación.

También debe evitar extender System.Object ya que no todos los lenguajes .NET podrán llamar al método de extensión como una extensión. (VB.NET, por ejemplo, necesitaría llamarlo como un método estático regular en la clase de extensión estática.)

No defina un método de extensión en el mismo espacio de nombres como el tipo extendido a menos que amplíe una interfaz.

No defina un método de extensión con la misma firma como método "real" ya que nunca se llamará.

Answer 6

Cuando me enteré de las Extensiones realmente abusé de ellas y abusé de ellas.

En general, he empezado a evitar el uso de cualquier método de extensión por varias razones.

Algunas de las razones por las que dejé de utilizarlas se indican en el enlace del blog de Scott anterior, como "Piensa dos veces antes de extender tipos que no te pertenecen". Si no tiene control sobre la fuente para los tipos que está extendiendo, puede encontrar problemas/colisiones en el futuro si el tipo de fuente tiene algunas adiciones/cambios, como mover su proyecto a una versión .NET más nueva. Si la nueva versión de .NET incluye un método del tipo del mismo nombre que su extensión, alguien será derrotado.

La razón principal por la que dejé de usar los Métodos de extensión es que no puede ver rápidamente al leer el código donde está el origen del método y quién lo "posee".

Al leer el código, no se puede decir si el método es una extensión o simplemente un método NET API estándar del tipo.

El menú intellisense puede ser muy complicado muy rápido.