C# Métodos de extensión - patrones de diseño

Question

Me gustaría saber si el método de extensión C# se basa en cualquier patrón de diseño existente.

Answer 1

Un patrón de diseño es simplemente un paradigma bien conocido, es decir, "cuando quiere lograr X, haga Y". Un paradigma bien conocido en lenguajes orientados a objetos como C# es "cuando desee actuar sobre el estado de un objeto, llame a un método en una instancia de este".

Sin embargo, antes de crear métodos de extensión, no podía invocar su propio método en una instancia de un objeto al que no podía agregar una implementación (por ejemplo, interfaces porque no pueden tener implementaciones o clases de biblioteca porque ya están compiladas)) Los métodos de extensión llenan este vacío al permitir que los métodos que aparezcan como se puedan llamar en instancias de objetos, mientras se definen externamente para la implementación del objeto.

Así que sí, podría decirse que los métodos de extensión se basan en este patrón de diseño muy simple, que hace que los métodos que actúan sobre el estado de un objeto parezcan exigibles a partir de una instancia de este.

Answer 2

No. Es solo una característica de idioma.

Answer 3

Por supuesto, puede utilizar los métodos de extensión C# si desea implementar ciertos patrones de diseño. Por ejemplo, simule mixins en C#.

Answer 4

no me etiquetar métodos de extensión como cualquiera de los patrones de diseño comunes, pero puede ser utilizado para implementar patrones como, decorador y el adaptador etc ..

Answer 5

Ellos no se basan en un patrón de diseño existente. Cuando esta 'característica' se introdujo por primera vez en Delphi, bajo el nombre 'class helpers', Borland incluso advirtió a los usuarios que se alejaran de ellos. They were considered a bit of a hack, pero ahora que el polvo se ha asentado, han encontrado un lugar propio.

Como todo lo demás, utilícelo cuando corresponda.

Answer 6

No, no lo son, porque solo son azúcar sintáctico.

Answer 7

Los métodos de extensión se pueden considerar como un reemplazo del Visitor Pattern. También se propone que se puedan usar como Adapters.

En general, los idiomas evolucionan para hacer que la necesidad de patrones de diseño sea menos necesaria. Hay una cita, por ejemplo, que Lisp no necesita patrones de diseño, porque todo está construido en el lenguaje. Entonces, la pregunta correcta será, ¿qué patrones de diseño reemplazan los métodos de extensión?

Answer 8

Los patrones de diseño canónico más cercanos son probablemente el Decorator pattern.

Answer 9

No, pero los métodos de extensión son excelentes para implementar ciertos patrones de diseño de GoF (p. Ej., Prototipo).

Answer 10

El mejor patrón de diseño que coincide con el método de extensión es el patrón de fachada. Mi razón: Usualmente usamos métodos de extensión para no introducir una nueva funcionalidad más allá de la responsabilidad de la clase objetivo, pero simplificando el uso de la clase objetivo existente. Debido a que la simplificación del uso de la clase de destino es la preocupación del patrón de fachada, los métodos de extensión alternativamente se pueden implementar utilizando el patrón de fachada. Existen algunos problemas para extender y probar los métodos de extensión de prueba. Así que creo que la implementación del patrón de fachada es un mejor enfoque contra el uso de métodos de extensión. Sin embargo, es posible implementar algunos métodos de extensión que envuelven la interfaz de fachada para proporcionar un recurso de codificación para los códigos de cliente.