metodos metodo mandar llamar invocar extension ejemplos definicion como clases anidados c# extension-methods

mandar - metodos anidados c#



¿Cómo gestionas los espacios de nombres de tus métodos de extensión? (6)

¿Utiliza un espacio de nombres global y global para todos sus métodos de extensión, o coloca los métodos de extensión en el mismo espacio de nombres que las clases que extienden?

¿O utiliza algún otro método, como una aplicación o espacio de nombres específico de la biblioteca?

Lo pregunto porque tengo la necesidad de extender System.Security.Principal.IIdentity , y poner el método de extensión en el espacio de nombres System.Security.Principal parece tener sentido, pero nunca lo he visto hacer de esta manera.


Actualicé la respuesta del usuario 276695, que parecía la solución más sencilla. Sin embargo, encontré una solución aún mejor: no hay ningún espacio de nombres. Puede colocar una clase estática con métodos de extensión en la raíz misma de un archivo, sin ajustar ninguna declaración de espacio de nombres a su alrededor. Luego, los métodos de extensión estarán disponibles sin tener que importar / usar ningún espacio de nombres. †

Estoy un poco preocupado por ser rechazado por los nazis del espacio de nombres. Pero me siento obligado a defender una posición ligeramente poco ortodoxa. Al menos en mi línea de trabajo (IT), encuentro que la mayoría de mis herramientas personalizadas son más fáciles de mantener sin espacios de nombres, y colocando todo en un espacio de nombres anónimo gigante. Estoy seguro de que hay otros universos de programación donde esto no funcionaría tan bien. Pero, dado que las circunstancias y las circunstancias son diferentes, solo quería señalar que, de hecho, puede declarar clases sin espacios de nombres, incluso clases con métodos de extensión, para aquellos que también encuentran mejor un espacio de nombres anónimo gigante.

† También puedes guardar un nivel de sangría. :-) E incluso con 3 monitores gigantes, siempre estoy buscando formas de guardar la pantalla de bienes raíces.


Mi práctica es colocar las extensiones en un espacio de nombres que sea diferente pero que identifique claramente el espacio de nombres de origen que estoy extendiendo.

En general, creo un espacio de nombres prefijando la parte de "nombre de la compañía" de la ruta del espacio de nombres frente al espacio de nombres que estoy extendiendo, y luego lo coloco con ".Extensiones"

Por ejemplo, si estoy extendiendo (sin ninguna razón) ::System.Text.StringBuilder porque está sellado, pondré mis extensiones en el espacio de nombres ::CodeCharm.System.Text.Extensions .

Esa es una regla de oro para cuando hago extensiones que sospecho que podría reutilizar esas extensiones en otras soluciones.


Ponga sus extensiones en el mismo espacio de nombres que las clases que extienden. De esa manera, cuando usas la clase, las extensiones están disponibles para ti.

  • Si está escribiendo una extensión para Uri, ponga la extensión en Sistema.
  • Si es una extensión para DataSet, póngala en System.Data.

Además, Microsoft dice esto sobre los métodos de extensión:

En general, le recomendamos que implemente los métodos de extensión con moderación y solo cuando sea necesario. Siempre que sea posible, el código de cliente que debe extender un tipo existente debe hacerlo creando un nuevo tipo derivado del tipo existente.

Para obtener más información sobre los métodos de extensión, consulte la página de MSDN sobre métodos de extensión.


Recomendaría poner todos sus métodos de extensión en un solo espacio de nombres (por cierto, esto también es lo que Microsoft hizo con Linq al colocarlos en una sola clase ''Extensiones'' dentro del espacio de nombres ''System.Linq'').

Ya que Visual Studio no proporciona pistas sobre cómo localizar un método de extensión que desee usar, reduce la confusión al tener que recordar solo un espacio de nombres.


Si los coloca en un espacio de nombres más alto que el actual, serán visibles automáticamente.

Así que si tienes espacios de nombres para proyectos como:

AdventureWorksInc.Web AdventureWorksInc.Logic AdventureWorksInc.DataAccess

Luego declara tu extensión directamente en:

namespace AdventureWorksInc { public static class HtmlHelpers { public static string AutoCloseHtmlTags(this string html) { //... } } }

Este método de extensión se mostrará cada vez que escriba código en cualquier espacio de nombre secundario de AdventureWorksInc sin la necesidad de una declaración de uso.

Sin embargo, la extensión anterior demuestra un posible inconveniente. Debido al hecho de que funciona en cadenas, ahora se mostrará como un método de extensión para todas las cadenas, incluidas aquellas que no son realmente HTML. En realidad, esto no es un problema con el alcance del espacio de nombres, sino simplemente un mal uso de un método de extensión. Esto debería ser una estática regular que requiera un parámetro estándar para que la llamada sea explícita.

En general, los métodos de extensión bien diseñados con los parámetros escritos correctamente no aparecerán en tipos que nunca se aplicarían.


Si son métodos de extensión utilizados en toda la solución (por ejemplo, más del 60% de las clases), los coloco en el espacio de nombres base de la solución (ya que se importarán automáticamente en un espacio de nombres principal, sin importar las cosas comunes cada vez) ).

En esta categoría, cosas como:
.IsNullOrEmpty(this string value) y .HasValue(this string value)

Sin embargo, si son muy específicos y rara vez se usan, los puse en un espacio de nombres de BaseNamepace.Extensions por lo que deben ser importados manualmente y no aparecer en todas partes.