Compartir vía

Métodos de extensión

  • Artículo

Nota:

Este contenido se ha copiado con permiso de Pearson Education, Inc. de Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2ª edición. Esa edición se publicó en 2008 y el libro se ha revisado completamente en la tercera edición. Parte de la información de esta página puede estar obsoleta.

Los métodos de extensión son una característica de lenguaje que permite llamar a métodos estáticos mediante la sintaxis de llamada de método de instancia. Estos métodos deben tomar al menos un parámetro, que representa la instancia en la que operará el método.

La clase que define tales métodos de extensión se conoce como la clase "patrocinador" y se debe declarar como estática. Para usar métodos de extensión, debe importar el espacio de nombres que define la clase patrocinador.

❌ EVITE definir frívolamente métodos de extensión, especialmente en tipos que no le pertenecen.

Si posee el propio código fuente de un tipo, plantéese la posibilidad de usar métodos de instancia normales en su lugar. Si no es el propietario y desea agregar un método, tenga mucho cuidado. El uso liberal de los métodos de extensión tiene el potencial de saturar las API de los tipos que no se diseñaron para tener estos métodos.

✔️ PLANTÉESE la posibilidad de usar métodos de extensión en cualquiera de los escenarios siguientes:

  • Para proporcionar una funcionalidad auxiliar relevante para cada implementación de una interfaz, si dicha funcionalidad se puede escribir en términos de la interfaz principal. Esto se debe a que las implementaciones concretas no pueden asignarse a interfaces de otro modo. Por ejemplo, los operadores LINQ to Objects se implementan como métodos de extensión para todos los tipos IEnumerable<T>. Por lo tanto, cualquier implementación de IEnumerable<> se habilita automáticamente para LINQ.

  • Cuando un método de instancia introduciría una dependencia en algún tipo, pero tal dependencia rompería las reglas de administración de dependencias. Por ejemplo, una dependencia de String a System.Uri probablemente no sea deseable, por lo que el método de instancia String.ToUri() que devuelve System.Uri sería el diseño equivocado desde una perspectiva de administración de dependencias. Un método de extensión estático Uri.ToUri(this string str) que devuelve System.Uri sería un diseño mucho mejor.

❌ EVITE definir métodos de extensión en System.Object.

Los usuarios de VB no podrán llamar a estos métodos en referencias a objetos mediante la sintaxis del método de extensión. VB no admite la llamada a tales métodos porque, en VB, la declaración de una referencia como Objeto obliga a que todas sus invocaciones de método estén enlazadas tardíamente (el miembro que llega a ser llamado se determina durante el tiempo de ejecución), mientras que los enlaces a los métodos de extensión se determinan durante el tiempo de compilación (enlazados tempranamente).

Tenga en cuenta que la instrucción se aplica a otros lenguajes en los que está presente el mismo comportamiento de enlace o donde no se admiten los métodos de extensión.

❌ NO coloque métodos de extensión en el mismo espacio de nombres que el tipo extendido a menos que sea para agregar métodos a interfaces o para la administración de dependencias.

❌ EVITE definir dos o más métodos de extensión con la misma firma, aunque residan en diferentes espacios de nombres.

✔️ PLANTÉESE la posibilidad de definir métodos de extensión en el mismo espacio de nombres que el tipo extendido si el tipo es una interfaz y si los métodos de extensión están diseñados para usarse en la mayoría de los casos o en todos ellos.

❌ NO defina métodos de extensión que implementen una característica en espacios de nombres que normalmente están asociados a otras características. En su lugar, defínalos en el espacio de nombres asociado a la característica a la que pertenecen.

❌ EVITE el nombre genérico de los espacios de nombres dedicados a métodos de extensión (por ejemplo, "Extensions"). En su lugar, use un nombre descriptivo (por ejemplo, "Enrutamiento").

Portions © 2005, 2009 Microsoft Corporation. Todos los derechos reservados.

Material reimpreso con el consentimiento de Pearson Education, Inc. y extraído de Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition (Instrucciones de diseño de .NET Framework: convenciones, expresiones y patrones para bibliotecas .NET reutilizables, 2.ª edición), de Krzysztof Cwalina y Brad Abrams, publicado el 22 de octubre de 2008 por Addison-Wesley Professional como parte de la serie Microsoft Windows Development.

Vea también