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

votos
37

He visto que se usan de todas maneras, y se me ha acusado de usarlos de la manera equivocada (aunque en ese caso, los estaba usando de esa manera para demostrar un punto ).

Entonces, ¿cuáles crees que son las mejores prácticas para emplear métodos de extensión?

¿Deben los equipos de desarrollo 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 de la organización

Publicado el 06/08/2008 a las 08:52
fuente por usuario
En otros idiomas...                            


6 respuestas

votos
7

El próximo lanzamiento de las Pautas de diseño de marco, 2da edición tendrá algunas pautas para implementar métodos de extensión, pero en general:

Solo debe definir los métodos de extensión "donde tengan sentido semántico" y proporcionen la funcionalidad de ayuda 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 esté ampliando una interfaz.

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

Respondida el 16/08/2008 a las 18:41
fuente por usuario

votos
4

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.

Respondida el 07/08/2008 a las 13:14
fuente por usuario

votos
3

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 de NetNewsWire para Mac OS X y iPhone) acaba de publicar hoy sus nuevas reglas de estilo para el uso de categorías y ha habido un poco de debate en la comunidad Cocoa en torno a esa publicación.

Respondida el 08/08/2008 a las 08:46
fuente por usuario

votos
3

He incluido mis métodos de extensión en mis bibliotecas Core en la clase Utils porque es probable que las personas que trabajan con mi framework encuentren útiles los métodos, pero para una implementación masiva donde el desarrollador final pueda tener la opción de bibliotecas de métodos de extensión, Aconsejaría poner todas sus extensiones en su propio espacio de nombres, incluso en su propio archivo de proyecto, para que las personas puedan optar por agregar una referencia o una declaración de uso 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.

Respondida el 06/08/2008 a las 09:08
fuente por usuario

votos
2

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

  • Los métodos de extensión que se relacionan con las necesidades comerciales específicas de un proyecto (ya sea que estén conectados a tipos de datos básicos u objetos personalizados) no deberían incluirse en una biblioteca que se distribuiría en varios proyectos.
  • Los métodos de extensión que se relacionan con tipos de datos básicos (int, cadena, etc.) o 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.

Respondida el 06/08/2008 a las 09:02
fuente por usuario

votos
1

Cuando primero descubrí sobre las extensiones que realmente usado en exceso y abusado de ellos.

En su mayor parte he empezado a alejarse de utilizar cualquiera de los métodos de extensión para un número de razones.

Algunas de las razones por las que dejó de usar ellos se indican en enlace del blog de Scott anteriormente, tales como "pensar dos veces antes de extender tipos que no posee". Si no tiene ningún control sobre la fuente de los tipos que se extienden, puede encontrarse con problemas / colisiones en el futuro si el tipo de fuente tiene algunas adiciones / cambios, como mover su proyecto a una nueva versión .NET. Si la versión más reciente de .NET incluye un método del tipo del mismo nombre que su extensión, alguien se va a poner una paliza.

La razón principal por la que he dejado de utilizar métodos de extensión es que no se puede saber rápidamente de la lectura del código, donde la fuente del método es y que "posee" la misma.

Cuando sólo la lectura a través del código no se puede saber si el método es una extensión o sólo un método de API NET estándar en el tipo.

El menú IntelliSense puede volver muy sucia muy rápido.

Respondida el 15/07/2013 a las 21:07
fuente por usuario

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more