Compartir a través de

Métodos de extensión

Nota:

Este contenido se vuelve a imprimir con el permiso de Pearson Education, Inc. de Directrices de diseño de frameworks: Convenciones, expresiones y patrones para bibliotecas reutilizables de .NET, 2ª Edición. Esa edición fue publicada en 2008, y el libro ha sido totalmente revisado 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 al método de instancia. Estos métodos deben tomar al menos un parámetro, que representa la instancia en la que se va a operar el método.

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

❌ EVITE definir frívolamente los métodos de extensión, especialmente en los tipos que no son de su propiedad.

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

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

  • Para proporcionar 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 se pueden asignar de otro modo a interfaces. Por ejemplo, los LINQ to Objects operadores se implementan como métodos de extensión para todos los IEnumerable<T> tipos. Por lo tanto, cualquier IEnumerable<> implementación está habilitada automáticamente para LINQ.

  • Cuando un método de instancia introduciría una dependencia en algún tipo, pero dicha dependencia interrumpiría las reglas de administración de dependencias. Por ejemplo, es probable que una dependencia de String a System.Uri no sea deseable, por lo que String.ToUri() el método de instancia que devuelve System.Uri sería el diseño incorrecto desde una perspectiva de administración de dependencias. Un método Uri.ToUri(this string str) de extensión estático 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 de objetos mediante la sintaxis del método de extensión. VB no admite llamar a tales métodos porque, en VB, declarar una referencia como Object obliga a que todas las invocaciones de método en ella se enlacen tardíamente (el miembro real llamado se determina en tiempo de ejecución), mientras que los enlaces a los métodos de extensión se determinan en tiempo de compilación (enlazados anticipadamente).

Tenga en cuenta que la guía 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, incluso si residen en espacios de nombres diferentes.

✔️ CONSIDERE 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 o todos los casos.

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

❌ EVITE la nomenclatura genérica de espacios de nombres dedicados a métodos de extensión (por ejemplo, "Extensiones"). Use un nombre descriptivo (por ejemplo, "Enrutamiento") en su lugar.

© Partes 2005, 2009 de Microsoft Corporation. Todos los derechos reservados.

Reimpreso con permiso de Pearson Education, Inc. de Framework Design Guidelines: Convenciones, Idiomas y Patrones para Bibliotecas .NET Reusables, 2ª Edición por Krzysztof Cwalina y Brad Abrams, publicado el 22 de octubre de 2008 por Addison-Wesley Professional como parte de la Serie Desarrollo de Microsoft Windows.

Consulte también