oop - strategy - patron template method
Estrategia vs patrones de puente (8)
Patrón de estrategia
Este patrón permite que el algoritmo que se ejecuta varíe independientemente de los clientes que lo usan. es decir, en lugar de tener un algoritmo fijo para exponer para una ubicación determinada, permite que uno entre muchos algoritmos se seleccione sobre la marcha en el tiempo de ejecución . Esto implica eliminar un algoritmo de su clase de host y ponerlo en una clase separada.
Por ejemplo, supongamos que uno quiere viajar de una ciudad a otra, y luego tiene varias opciones: tomar un autobús, alquilar un automóvil, tomar un tren, etc. De modo que cada modo de transporte seleccionado transpiraría en un algoritmo separado para ser ejecutado. El modo de transporte elegido dependerá de varios factores decididos en tiempo de ejecución (costo, tiempo, etc.). En otras palabras, la estrategia elegida para ejecutar se decidirá sobre la marcha.
Otro ejemplo, supongamos que uno quiere implementar una clase SortedList (controlador principal) que Sorts función de una strategy . La estrategia es el método que uno usa para clasificar (como MergeSort, QuickSort).
Comparación con el patrón Bridge
La principal diferencia (aunque ambos patrones tienen el mismo UML) es que, a diferencia del patrón de puente (que es un patrón estructural), el patrón de estrategia es un patrón de comportamiento. Los patrones estructurales sugieren formas en que los objetos se componen o se asocian o se heredan para formar objetos más grandes, es decir, se enfocan en la composición del objeto. Si bien los patrones de comportamiento se relacionan con el algoritmo o la lógica comercial (y no con la creación del objeto en sí), se centran en la colaboración entre objetos.
Tenga en cuenta que la mayoría de los algoritmos se pueden implementar como clases estáticas o singleton que requieren solo creación de instancia única (es decir, no se requiere new cada vez que se establece una estrategia).
Una mirada más cercana a la implementación de los dos patrones revelará que en el patrón del puente uno crea la implementación concreta del objeto y luego la llamada.
// Set implementation and call
// i.e. Returns (creates) the concrete implementation of the object,
// subsequently operation is called on the concrete implementation
ab.Implementor = new ConcreteImplementorA();
ab.Operation();
Mientras que en el caso del patrón de estrategia, uno no usará la implementación concreta del algoritmo directamente, sino que creará el contexto en el que la estrategia debería ejecutarse,
// Set the context with a strategy
// i.e. Sets the concrete strategy into the context, concrete implementation of the class not
// directly available as a data object (only the algorithm is available).
context = new Context (new ConcreteStrategyA());
context.contextInterface();
// Strategy can be reused instead of creating a new instance every time it is used.
// Sort example
MergeSort mergeSort = new MergeSort();
QuickSort quickSort = new QuickSort();
...
context = new Context (mergeSort);
context.Sort();
...
context = new Context (quickSort);
context.Sort();
...
context = new Context (mergeSort);
context.Sort();
Sé que esta pregunta se ha formulado antes (por ejemplo, ¿cuál es la diferencia entre el patrón del puente y el patrón de la estrategia? ).
Sin embargo, ¿podría alguien explicar, usando ejemplos bien definidos, cuál es la diferencia y en qué tipo de casos se debe seleccionar uno sobre el otro? Menos teoría conceptual, se apreciarían escenarios más prácticos de la "vida real".
Ambos patrones separan la interfaz de la implementación. Creo que la diferencia clave es que Bridge Pattern usa la herencia ("is a") mientras que Strategy Pattern usa la composición ("tiene un").
Patrón de puente:
class Sorter abstract
{
virtual void Sort() = 0;
}
// MergeSorter IS A Sorter
class MergeSorter : public Sorter
{
virtual void Sort() override;
}
Patrón de estrategia:
class SortStrategy abstract
{
virtual void Sort() = 0;
}
// Sorter HAS A SortStrategy
class Sorter
{
Sorter(SortStragety *strategy) : mStrat(strategy) {}
void Sort() {mStrat->Sort();}
SortStrategy *mStrat;
}
El patrón Bridge explica cómo organizar las clases, la Estrategia, cómo organizar los algoritmos.
El patrón de Estrategia encapsula algoritmos para que puedan ser usados y cambiados en un programa complejo (sin engomado de las obras) y el patrón Puente permite que dos interfaces se enlacen de manera flexible para que puedan interactuar pero cambiarse independientemente una de la otra.
Aquí puedes encontrar ejemplos de PHP de los patrones Bridge y Strategy:
http://www.php5dp.com/category/design-patterns/bridge/
y
http://www.php5dp.com/category/design-patterns/strategy/
Encontrarás muchos ejemplos para ambos patrones que pueden ser útiles.
Permítanme recitar las respuestas de la pregunta vinculada.
El patrón de puente es un patrón estructural, es decir, establece ideas de cómo construir un componente de su proyecto. Se usa para ocultar dos niveles de abstracciones. El código de muestra en Wikipedia (http://en.wikipedia.org/wiki/Bridge_pattern) lo explica en la mayoría de los términos inequívocos.
El patrón de estrategia es un patrón dinámico. Cuando cualquier función wild puede implementar los requisitos, se usa un patrón de estrategia. Los ejemplos pueden ser cualquier programa que permita desarrollar e instalar complementos. En la página de Wikipedia (http://en.wikipedia.org/wiki/Strategy_pattern), ConcreteStrategyAdd, ConcreteStrategySubtract, etc. es un complemento utilizado en la clase ConcreteStrategy. Cualquier método se podría usar allí que implemente la interfaz Estrategia.
Puedo decir que esto es difícil de explicar. Muchas personas que lo usan y lo entienden tienen dificultades para explicárselo a los novatos.
Para aquellos como yo que piensan en términos de analogías:
Patrón de estrategia
Entonces la estrategia es una especie de concepto unidimensional. Piense en una matriz unidimensional de estrategias para elegir.
Ejemplo 1: herramientas de plomero
El patrón de estrategia es como un plomero que tiene varias herramientas para desatascar una tubería. El trabajo es el mismo cada vez; es para destapar la tubería. Pero la herramienta que elige para hacer esto puede variar según la situación. Tal vez intente con uno y si eso no funciona, probará con otro.
En esta analogía, "desatascar la tubería" es el método que implementará una de las estrategias. El pincel de serpiente, el sinfín de potencia y el draino son las estrategias concretas, y el fontanero es la clase que contiene el método (etiquetado como "Contexto" en la mayoría de los diagramas).
Ejemplo 2: destornillador de múltiples puntas
O podrías pensar en los bits intercambiables en un destornillador de varios bits. Están destinados a ser cambiados en tiempo de ejecución para adaptarse al trabajo en cuestión, que es atornillar algo.
Patrón de puente
Entonces bridge es un concepto bidimensional. Piense en una dimensión (las filas) que es la lista de métodos que deben implementarse, y la segunda dimensión (las columnas) son los Implementadores que implementarán cada uno de esos métodos.
Ejemplo 1: aplicaciones y dispositivos
El patrón de puente es como una persona que tiene muchas formas de comunicarse (correo electrónico, texto, voz de google, teléfono, skype) y muchos dispositivos con los que se pueden comunicar de varias maneras: una PC, una tableta y un dispositivo inteligente. teléfono.
Las diversas formas de comunicarse (correo electrónico, texto, teléfono) serían los métodos en una interfaz abstracta, llamémoslo "Dispositivo de comunicación". En este patrón, CommunicationDevice es el implementador. Cada dispositivo en esta analogía (PC, tableta, teléfono inteligente) es el ConcreteImplementor que implementa todos estos métodos (correo electrónico, texto, teléfono).
Ejemplo 2: controladores de base de datos Odbc y funciones odbc
Otro ejemplo listo de bridge son los módulos de controlador de base de datos odbc u oledb de Windows. Todos implementan varios métodos en la misma interfaz estándar de "controlador de base de datos", pero implementan esa interfaz de diferentes maneras. Incluso si está utilizando la misma base de datos, diga Sql Server, todavía hay diferentes controladores que pueden comunicarse con Sql Server, aunque de diferentes maneras bajo las coberturas.
The Bridge Pattern hace una distinción entre una abstracción y una implementación de tal manera que las dos pueden variar de forma independiente. Usaré el ejemplo de
Patrones en Java, Volumen 1: Un catálogo de patrones de diseño reutilizables ilustrados con UML, segunda edición
Debe proporcionar clases que accedan a sensores físicos como los encontrados en básculas, dispositivos de medición de velocidad, etc. Cada sensor produce un número, pero el número podría significar cosas diferentes. Para la balanza puede significar el peso y para el dispositivo de medición de velocidad puede significar velocidad.
Por lo tanto, puede comenzar creando una clase abstracta de Sensor para representar la característica común entre todos los sensores y varias subclases para los diferentes tipos de sensores. Este es un diseño robusto que le permite proporcionar muchos más tipos de sensores en el futuro.
Ahora supongamos que los sensores son provistos por diferentes fabricantes. Deberá crear una jerarquía de clases de sensores para el fabricante X y otra para el fabricante Y. El problema ahora es que los clientes necesitarían saber la diferencia entre los fabricantes. Y si decides apoyar a un tercer fabricante ...?
La solución es proporcionar la jerarquía de abstracción principal, es decir. la clase abstracta del sensor y las subclases como SpeedSensor y WeightSensor, etc. A continuación, proporcione la interfaz (Bridge) que existirá entre la abstracción y la implementación. Por lo tanto, habrá un SensorInterface, WeightSensorInterface y SpeedSensorInterface, que dictará la interfaz que cada clase de sensor concreto debe proporcionar. La abstracción no conoce la implementación, más bien conoce la interfaz. Finalmente, puede crear una implementación concreate para cada fabricante. Es decir, XSensor, XWeightSensor y XSpeedSensor, YSensor, YSpeedSensor y YWeightSensor.
Los clientes dependen solo de la abstracción, pero cualquier implementación podría estar conectada. Por lo tanto, en esta configuración, la abstracción podría cambiarse sin cambiar ninguna de las clases concretas, y la implementación podría cambiarse sin preocuparse por la abstracción.
Como puede ver, esto describe una forma de estructurar sus clases.
Por otro lado, la Estrategia se ocupa de cambiar el comportamiento de un objeto en tiempo de ejecución. Me gusta usar el ejemplo de un juego con un personaje que posee varios tipos diferentes de armas. El personaje puede atacar, pero el comportamiento del ataque depende del arma que el personaje tenga en ese momento, y esto no se puede conocer en el momento de la compilación.
Entonces haces que el comportamiento del arma se pueda conectar e inyectarlo en el personaje según sea necesario. De ahí un patrón de comportamiento.
Estos dos patrones resuelven diferentes problemas. La estrategia tiene que ver con hacer que los algoritmos sean intercambiables, mientras que el Puente se ocupa de desacoplar la abstracción de la implementación para que pueda proporcionar múltiples implementaciones para la misma abstracción. Es decir, el puente se refiere a estructuras enteras.
Aquí hay algunos enlaces que pueden ser útiles:
Estrategia:
La estrategia es un patrón de diseño de comportamiento. Si se usa para cambiar entre familia de algoritmos.
Este patrón contiene una interfaz de estrategia abstracta y muchas implementaciones de estrategia concretas ( algoritmos ) de esa interfaz.
La aplicación usa solo la interfaz de estrategia. Dependiendo de algún parámetro de configuración, la estrategia concreta se etiquetará a la interfaz .
Puente:
- Permite que tanto las abstracciones como las implementaciones varíen de forma independiente .
- Utiliza la composición sobre la herencia.
- El puente es un patrón estructural .
por ejemplo, clases de colección en java.util. List java.util. List implementada por ArrayList .
Sin embargo, ¿podría alguien explicar, usando ejemplos bien definidos, cuál es la diferencia y en qué tipo de casos se debe seleccionar uno sobre el otro?
Consulte la publicación a continuación para obtener información sobre los casos de uso de los patrones de Estrategia y Puente:
¿Cuál es la diferencia entre el patrón del puente y el patrón de estrategia?
En una nota rápida:
Utilice el patrón Estrategia para cambiar dinámicamente la implementación al reemplazar una estrategia por otra estrategia.
Un ejemplo de palabra real: aerolíneas que ofrecen descuentos durante los meses de poca actividad . Simplemente cambie la estrategia de descuento de tarifas con una estrategia sin descuentos durante el tiempo pico alto.
Utilice el patrón Bridge cuando las abstracciones y las implementaciones no se hayan decidido en el momento de la compilación y puedan variar de forma independiente
Un ejemplo del mundo real en la industria del automóvil: diferentes tipos de engranajes se pueden ensamblar en diferentes tipos de automóviles . Las especificaciones y la implementación de Car y Gear pueden cambiar de forma independiente.