2009-08-04 16 views
38

Sé que ya existe un post, que describe casi lo mismo, pero creo que el mío es un poco diferente.Mejores prácticas: C# Espacio de nombres de métodos de extensión y promoción de métodos de extensión

Lo que me gustaría saber es cómo organiza sus métodos de extensión en términos de asignación del espacio de nombres. Actualmente - para los métodos de extensión en nuestro marco - utilizo el siguiente patrón de espacio de nombres

  • MyCompany.Web.Utils

y en el interior Tengo las clases método de extensión. Esto está bien para mí con la desventaja de que los extensores no son inmediatamente visibles para nuestros desarrolladores de software. Considere el caso donde tengo una clase StringExtender que proporciona un muy útil extension method "In" que extiende el objeto String. Teniendo el método de extensión dentro del espacio de nombres mencionado anteriormente, nuestros programadores no verán el método de extensión a menos que incluyan explícitamente su espacio de nombres. En cambio, si pongo el método de extensión en el espacio de nombre System, todos lo verán de inmediato, pero tengo read that this is bad practice.

Así que mi pregunta es cómo promocionar sus métodos de extensión a la vez son utilizados por tus desarrolladores.

Respuesta

31

Ponemos a todos en su propio espacio de nombre Company.Common.Extensions. De esta forma, si tiene alguno de nuestros métodos de extensión, los tiene todos. Además, al menos en mi tienda, no tenemos que preocuparnos de que nuestros desarrolladores no conozcan los métodos de extensión. Tengo la preocupación opuesta, ¡sobrecarga del método de extensión! :)

+2

(1) Estoy de acuerdo, se utiliza un namingconvention donde añadimos .extensions al final. –

+0

+1. Buen punto sobre la sobrecarga del método de extensión. – RichardOD

+0

Eso es básicamente lo que estoy haciendo. Así que supongo que es la mejor manera de continuar así. Thx – Juri

3

@ Juri- Si lo piensas, este es el mismo problema que los desarrolladores sabiendo que la clase X existe en .NET Framework. La comunicación es clave para que todos los miembros del equipo utilicen las clases correctas, ya sean métodos de extensión o algún otro ayudante.

Como JP ha declarado, a menudo veo los métodos de extensión en algún tipo de subcarpeta llamada Extensiones. Afortunadamente, cuando diga que usa my.empresa.web.utils, ¿el espacio de nombres está realmente encasillado?

Incluso si los coloca en un buen lugar, no hay garantía del 100% de que otros desarrolladores los utilicen.

+0

sí, el nombre está encasillado en pascal ... no prestó atención al publicarlo aquí :) – Juri

9

El problema aquí no es la denominación del espacio de nombres, es la falta de documentación y educación de sus desarrolladores.

Colóquelos en el espacio de nombres que tenga sentido, escriba un artículo de wiki que documente todos sus métodos de extensión, luego envíe un correo electrónico a sus desarrolladores con un enlace al artículo de la wiki.

+0

Sí, esa era mi otra opción. La falta de comunicación suele ser un problema en los equipos de desarrollo de software. Ya estamos en el proceso de configurar una wiki, pero a menudo es bastante difícil, estar bajo presión de tiempo y no recibir apoyo de la gerencia en este tipo de actividades. Supongo que la gente sabe de lo que estoy hablando. – Juri

+3

Siento tu dolor. A veces me parece que es mejor seguir adelante y hacer estas cosas, hacer que la gente los use y ENTONCES decirle a la gerencia :) –

+0

El mismo punto que mi respuesta, pero +1 por mencionar el uso de una wiki. – RichardOD

3

Suponiendo que utilice Visual Studio, una forma sería crear una plantilla de clase personalizada (o modificar la predeterminada) para que cada vez que un desarrollador crea un nuevo archivo de clase tenga automáticamente una instrucción using con su espacio de nombres. Ver C ustomize Visual Studio 2005 Templates for Coding Productivity.

5

Esto no es un problema de espacio de nombres, es un problema de comunicación.

Si estos métodos son útiles, debe comunicar esto a los desarrolladores y, a la inversa, actuar en función de los comentarios de ellos (con los niveles de juicio adecuados).

Colocar cualquier cosa en el espacio de nombres del sistema es una receta para el desastre y la confusión posterior. Las únicas veces que quiera hacer esto es utilizar la funcionalidad de 'back-ports' en frameworks anteriores y entonces probablemente no deba hacerlo usted mismo, pero debería usar algo como LinqBridge para hacerlo.

Tenga cuidado con el deseo de tirar todas las extensiones en un espacio de nombres a menos que realmente son ampliamente útiles juntos. Algunos desarrolladores pueden encontrar la madera perdida para los árboles si son bombardeados con todo y el fregadero de la cocina a través de Intellisense.

Mantener el espacio de nombres del nombre de la empresa es razonable, en general, para evitar confusiones.

+0

"Tenga cuidado con el deseo de incluir todas las extensiones en un espacio de nombres a menos que realmente sean muy útiles en conjunto". Tenemos un número bastante limitado de métodos de extensión y también estamos tratando de mantenerlos pequeños. Entonces esto no debería ser un problema. – Juri

1

sí, creo que puse los métodos de extensión en la propia empresa es namespce mejores prácticas. ponerlo en espacio de nombres System es una operación perezoso

0

Ponemos todo en el mismo espacio de nombres y clase, sin embargo, utilizar las clases parciales para mantenerlos organizados.

Por ejemplo:

ExtensionMethods-String.cs

ExtensionMethods-DataObject.cs

ExtensionMethods-Debug.cs

etc ... todos tienen clases parciales ...

+2

¿Cuáles son las ventajas de usar clases parciales para los métodos de extensión? He visto a muchas personas colocar los métodos de extensión en un espacio de nombres .Extensiones y nombrar las clases y los archivos después de la clase que extienden: StringExtension.cs y clase estática pública StringExtensions {}. – CodeMonkeyKing

+0

@CodeMonkeyKing: se olvidan algunos métodos de extensión. Cuando trabajamos con una aplicación determinada, agregamos la extensión basada en la funcionalidad lógica, que a menudo no se alinea con el diseño de las clases .NET. Aunque me gusta tu enfoque también – LamonteCristo

0

se puede lograr lo que t O desea poniendo métodos de extensión en el espacio de nombres global. Eso es lo que hago y están disponibles sin necesidad de ninguna declaración using.

Cuestiones relacionadas