c# - poo - que es un patron diseño grafico

C#Patrón de diseño de estrategia por delegado vs OOP

Question

Me pregunto cuáles son las ventajas y desventajas de usar delegate vs OOP al implementar un patrón de diseño de estrategia.

¿Cuál me recomienda usar? ¿O qué tipo de problema resuelve el delegado? y ¿por qué deberíamos usar OOP si OOP es mejor?

¡Gracias!

-paso

Answer 1

A favor de los delegados:

• Los delegados son más fáciles de implementar de forma liviana utilizando expresiones lambda y métodos dinámicos
• Los delegados se pueden crear a partir de métodos "normales" con la firma correcta
• Los delegados que son multidifusión pueden ser útiles a veces (aunque relativamente raramente fuera de los eventos)

A favor de las interfaces:

• Un objeto puede implementar una interfaz y aún hacer otras cosas: un delegado es solo un delegado
• Una interfaz puede tener múltiples métodos; un delegado solo tiene el

Podría ir de cualquier manera:

• Con las interfaces terminas con dos nombres: la interfaz y el método. Con delegados solo tienes el uno. A menudo encuentro que las interfaces de un solo método repiten el mismo nombre dos veces (con variaciones) o el nombre del método es muy suave

Personalmente, soy un gran fanático de los delegados por su flexibilidad, pero realmente depende de la situación.

Answer 2

Ambas técnicas pueden ser poderosas y valiosas; aquí hay algunas de mis opiniones sobre cuándo usar cuáles.

Utilice un enfoque de Interfaz / Implementación cuando la estrategia:

2. mantiene el estado
3. necesita configuracion
4. usa inyección de dependencia
5. necesita ser configurado por un contenedor IoC (piense en ConnectionProvider)
6. combina múltiples responsabilidades (piense en DataAdapter de ADO.NET)
7. es demasiado complejo o largo como un solo método
8. es probable que sea subclasificado para crear nuevas estrategias
9. necesita devolver información de estado a la persona que llama
10. Necesita acceder a los elementos internos del objeto se aplica a
11. Requeriría demasiados parámetros directos

De lo contrario, tiende a utilizar delegados basados ​​en Func <> o Acción <>, especialmente si

1. Es probable que haya una gran variedad de estrategias (piense en las expresiones de clasificación)
2. La estrategia se expresa mejor como lambda
3. Hay un método existente que desea aprovechar

Answer 3

En mi opinión, si utiliza delegados, entonces no está implementando el patrón de la Estrategia . En realidad estás implementando algo más parecido al patrón Observer . El punto principal de los patrones de diseño es que cuando dices "He usado el patrón de Estrategia aquí", todos tienen mucho contexto sobre lo que has hecho. Cuando empiezas a decir cosas como "He usado el patrón de estrategia, excepto con mis propias modificaciones personales", las cosas se ponen feas.

Pero, si entiendo lo que intentas decir, una de las cosas agradables sobre el patrón de la Estrategia que no está tan claro con los delegados es que puedes tener una jerarquía de objetos que implementan una estrategia.

Digamos que estoy probando alguna pieza de software. Quiero probarlo usando el mouse y usando el teclado. Entonces, implementaré un patrón de Estrategia para conectar el método de interfaz que se usará para cada caso de prueba ... para poder escribir el caso de prueba una vez y ejecutarlo completamente usando MouseStrategy y KeyboardStrategy. Desde allí puedo implementar especializaciones como MouseExceptForDialogsStrategy, una especialización de MouseStrategy. Este tipo de jerarquía, cómo extenderla y anularla es fácil de entender para cualquier persona que esté familiarizada con los conceptos de POO ... mientras que la forma de lograr y extender lo mismo con los delegados es mucho más complicada y mucho más oscura.

Como con muchas cosas ... no es una cuestión de "¿puedes hacerlo?", Sino "¿deberías hacerlo?".

Answer 4

Me gusta usar una interfaz para abstraer mi estrategia. Mis implementaciones concretas tienen un archivo visible para cada estrategia. Cuando se trabaja con una clase en lugar de un método, le da más flexibilidad. Puedo usar Rhino para burlarse de la estrategia para probarla. También puedo usar fácilmente marcos de DI como Ninject para enlazar la estrategia de forma muy fácil. Uso delegados para extraer la implementación principalmente en los diálogos de WinForm.