design-patterns - example - design pattern handler
Diferencia entre patrón de estrategia y patrón de delegación. (4)
¿Cuál es la diferencia entre el patrón de estrategia y el patrón de delegación (no los delegados)?
"Delegación" no es realmente un patrón de diseño, es más bien una técnica de programación general, donde el componente A delega la tarea (cualquiera sea el tipo de tarea que pueda ser) al componente B. La delegación se puede utilizar en muchos contextos.
El patrón de estrategia, por otro lado, es un patrón específico que normalmente hace un uso intensivo de la delegación como detalle de implementación.
Por ejemplo, podría implementar el patrón de estrategia e invocarlo usando
strategy.execute(x)
El patrón de estrategia implica tener varias implementaciones de su interfaz de Estrategia y seleccionar la implementación adecuada en tiempo de ejecución. El acto de invocar esa implementación es delegación.
Así que no es ninguno de los dos, los conceptos son complementarios.
Aquí hay un pensamiento:
Los delegados imitan a la clase delegante (al menos como los he usado, no estoy seguro de si esa es la forma canónica o no, pero así es como normalmente lo hago). Básicamente, si tengo una clase que tiene varios puntos de entrada (métodos) y quiero cambiar la implementación en tiempo de ejecución, crearía delegados que implementen la misma interfaz.
Si, por otro lado, tuviera una parte de una clase que quisiera poder intercambiar en tiempo de ejecución, crearía clases de estrategia con una sola interfaz de método (por ejemplo, executeCalculation) y la convertiría en un componente agregado de la clase contenedora. .
Entonces, en resumen, una estrategia abarca un solo comportamiento, los delegados implementan un conjunto de comportamientos y usted podría usar delegados para implementar estrategias.
El patrón de estrategia es una solución de diseño muy específica para un problema de software común. El patrón de estrategia implica que habrá
- una interfaz llamada Estrategia (o con Estrategia como parte del nombre). esta interfaz debe tener un método llamado execute ().
- una o más clases concretas llamadas algo como ConcreteStrategyA, ConcreteStrategyB, etc. que implementan la interfaz de la Estrategia.
- También debería haber una clase de contexto que contenga la Estrategia.
La delegación es más un principio que un patrón. delegación implica que, en lugar de tener un solo objeto a cargo de todo, delega responsabilidades a otros objetos. La razón por la que esta técnica es común es que impone dos principios aún más fundamentales del desarrollo de software al disminuir el acoplamiento y aumentar la cohesión.
Habiendo dicho todo eso, no te preocupes por los patrones. Concéntrese en los directores y si cree que su solución podría mejorarse, mire los patrones para ver si hay una trampa para ratones mejor. Si se enfoca en patrones en lugar de principios, se encontrará perdido en todos los patrones e implementando patrones para implementar patrones ...
Si se refería al patrón de estrategia frente a los delegados, como en las funciones / lambdas pasadas como argumentos, entonces al menos sé que hay menos gastos generales en términos de clases que deben compilarse para los delegados.
De hecho, encontré esta página buscando a alguien para que me diera sus opiniones sobre los beneficios de seguir usando la ruta del patrón de diseño, dado que tanto Java como C # ahora admiten funciones de paso como argumentos.