Clasificación, intención y aplicabilidad de los patrones de diseño.

introducción

"Cada patrón describe un problema que se repite a nuestro alrededor y el núcleo de la solución a ese problema. De esta manera, puede usar la solución una y otra vez sin tener que reinventar la rueda". El núcleo del patrón de diseño es proporcionar soluciones a problemas relacionados, de modo que las personas puedan reutilizar diseños y arquitecturas exitosos de manera más simple y conveniente.

Clasificación

Patrones de diseño creacional

Los patrones de creación abstraen el proceso de creación de instancias y ayudan a que un sistema sea independiente de cómo se crean, componen y representan sus objetos. Un patrón de creación de clases utiliza la herencia para cambiar la clase de la que se crea una instancia, mientras que un patrón de creación de objetos delega la creación de instancias a otro objeto.

Método de fábrica

1. Intención
Defina una interfaz para crear objetos y deje que las subclases decidan qué clase instanciar. Factory Method difiere la instanciación de una clase a sus clases.
2. Estructura

• El producto define la interfaz para los objetos creados por el método de fábrica.
• ConcreteProduct implementa la interfaz Product.
• Creator declara un método de fábrica que devuelve un objeto de tipo Producto. Creator también puede definir una implementación predeterminada de un método de fábrica, que devuelve un objeto ConcreteProduct predeterminado, y puede llamar al método de fábrica para crear un objeto de Producto.
• ConcreteCreator redefine el método de fábrica para devolver una instancia de ConcreteProduct.

3. Aplicabilidad

• Cuando una clase no conoce la clase del objeto que debe crear.
• Cuando una clase quiere que sus subclases especifiquen los objetos que crea.
• Cuando una clase delega la responsabilidad de creación de objetos a una de varias subclases auxiliares y desea localizar la información sobre qué subclase auxiliar es la delegada.

Fábrica abstracta (Fábrica abstracta)

1. Intención

Proporciona una interfaz para crear una serie de objetos relacionados o interdependientes sin especificar sus clases concretas.

2. Estructura

• AbstractFactory declara una interfaz para operaciones que crean objetos de productos abstractos.
• ConcreteFactory implementa operaciones para crear objetos de productos concretos.
• AbstractProduct declara una interfaz para una clase de objetos Product.
• ConcreteProduct define un objeto de producto para ser creado por la fábrica concreta correspondiente, implementando la interfaz AbstractProduct.
• El cliente solo usa las interfaces declaradas por las clases AbstractFactory y AbstractProduct.

3. Aplicabilidad

• Cuando un sistema ha de ser independiente de la creación, composición y presentación de sus productos.
• Cuando se va a configurar un sistema a partir de una de varias familias de productos.
• Cuando se deba enfatizar el diseño de una serie de objetos de productos relacionados para uso conjunto.
• Al proporcionar una biblioteca de clases de productos y solo desea mostrar sus interfaces pero no sus implementaciones.

Constructor

1. La intención
es separar la construcción de un objeto complejo de su representación, de modo que un mismo proceso de construcción pueda crear representaciones diferentes.

2. Estructura

• Builder especifica interfaces abstractas para los diversos componentes que crean un objeto Producto.
• ConcreteBuilder implementa la interfaz Builder para construir y ensamblar los diversos componentes del producto, definir las representaciones que crea y proporcionar una interfaz para recuperar el producto.
• Director construye un objeto utilizando la interfaz Builder.
• El producto representa el objeto complejo que se está construyendo. ConcreteBuilder crea el proceso interno de desarrollo de la granja para este producto. Contiene clases que definen los componentes constituyentes, incluidas las interfaces para ensamblar esos componentes en un producto final.

3. Aplicabilidad

• Cuando el algoritmo para crear un objeto complejo debe ser independiente de las partes constituyentes de ese objeto y de cómo se ensamblan.
• Cuando el procedimiento constructivo deba permitir diferentes representaciones de los objetos que se construyen.

Prototipo

1. Intención
Use la instancia de prototipo para especificar el tipo de objeto que se creará y cree nuevos objetos copiando estos prototipos.
2. Estructura

• Prototype declara una interfaz que se copia a sí misma.
• ConcretePrototype implementa una operación que se copia a sí misma.
• El cliente hace una copia prototipo de sí mismo para crear un nuevo objeto.

3. Aplicabilidad

• Cuando un sistema debe ser creado, compuesto y representado independientemente de sus productos.
• Cuando la clase a instanciar se especifica en tiempo de ejecución, por ejemplo, a través de carga dinámica.
• Para evitar crear una jerarquía de clases de fábrica paralela a la jerarquía de clases de productos.
• Cuando una instancia de una clase solo puede tener una de varias combinaciones diferentes de estados. Puede ser más conveniente crear una cantidad correspondiente de prototipos y clonarlos que instanciar manualmente la clase cada vez con el estado apropiado.

único

1. La intención
es garantizar que solo haya una instancia de una clase y proporcionar un punto de acceso global para acceder a ella.
2. Estructura

• Singleton especifica una operación de instancia que permite a los clientes acceder a su única instancia.
• Instancia es una operación de clase; posiblemente responsable de crear su propia instancia única.

3. Aplicabilidad

• Cuando una clase solo puede tener una instancia y los clientes pueden acceder a ella desde un punto de acceso conocido.
• Cuando la única instancia debe ser extensible a través de subclases y los clientes pueden usar una instancia extendida sin cambios de código.

Patrones de diseño estructural

Los patrones de diseño estructural se ocupan de cómo combinar clases y objetos para lograr una estructura más grande. El patrón de clase estructural utiliza el mecanismo de herencia para combinar interfaces o implementaciones. Un ejemplo simple es usar la herencia múltiple para combinar más de dos clases en una clase, como resultado, esta clase contiene todas las propiedades de la clase padre. Este patrón es especialmente útil para que varias bibliotecas de clases desarrolladas de forma independiente trabajen juntas.

Adaptador

1. Intención
Convertir la interfaz de una clase en otra interfaz que el cliente quiera. El patrón Adapter permite que las clases que de otro modo no funcionarían juntas debido a interfaces incompatibles trabajen juntas.

2. Los adaptadores estructurales
usan herencia múltiple para hacer coincidir una interfaz con otra


3. Aplicabilidad

• Desea utilizar una clase existente cuya interfaz no cumple con los requisitos.
• Desea crear una clase consumible que pueda funcionar con otras clases no relacionadas o clases imprevistas (es decir, clases cuyas interfaces pueden no ser necesariamente compatibles).
• (Solo adaptador de objetos) Quiere usar una subclase existente, pero no es posible subclasificar cada una para que coincida con su interfaz. Un adaptador de objetos puede adaptar su interfaz de superclase.

Puente

1. La intención
es separar la parte abstracta de su implementación para que ambas puedan variar de forma independiente.

2. Estructura

• Abstracción define la interfaz de la clase abstracta y mantiene un puntero al objeto de tipo Implementador.
• RefinedAbstraction amplía la interfaz definida por Abstraction.
• Implementor define la interfaz de la clase implementadora, que no tiene que ser exactamente la misma que la interfaz de Abstraction; de hecho, las dos interfaces pueden ser bastante diferentes. En general, la interfaz Implementor proporciona solo operaciones básicas, mientras que Abstraction define operaciones de nivel superior basadas en estas operaciones básicas.
• Concretelmplementor implementa la interfaz Implementor y define su implementación concreta.

3. Aplicabilidad

• No desea tener un enlace fijo entre una abstracción y su implementación. Este puede ser el caso, por ejemplo, porque la parte de implementación debe ser seleccionable o conmutable en tiempo de ejecución del programa.
• Tanto la abstracción de una clase como su implementación deben ser extensibles por medio de subclases. Este es el modo Bridge que permite a los desarrolladores combinar diferentes interfaces abstractas y partes de implementación y extenderlas por separado.
• Las modificaciones a una parte de implementación abstracta no deberían tener impacto en el cliente, es decir, no es necesario volver a compilar el código del cliente. (C++) quiere ocultar por completo la implementación de la abstracción de los clientes.
• Hay una jerarquía de clases con muchas clases para generar.
• Desea compartir la implementación (posiblemente utilizando el recuento de referencias) entre varios objetos, pero al mismo tiempo requiere que el cliente no lo sepa.

Compuesto

1. Intención
de combinar objetos en una estructura de árbol para representar una jerarquía de "parte-todo". Composite permite a los usuarios usar la consistencia específica de objetos individuales y objetos compuestos
2, estructura

• Component declara una interfaz para los objetos en la composición; implementa el comportamiento predeterminado de la interfaz común de todas las clases donde corresponda; declara una interfaz para acceder y administrar subcomponentes de Component; (opcional) define una interfaz en una estructura recursiva para acceder a un padre e implementarlo donde sea apropiado.
• Leaf representa el objeto de nodo de hoja en la combinación, y el nodo de hoja no tiene nodos secundarios; el comportamiento del objeto primitivo se define en la combinación.
• Composite define el comportamiento de esos componentes con subcomponentes; almacena subcomponentes; implementa operaciones relacionadas con subcomponentes en la interfaz de componentes.
• El cliente manipula los objetos de los componentes compuestos a través de la interfaz de componentes.

3. Aplicabilidad

• quieren representar la jerarquía parte-todo de los objetos.
• Se espera que el usuario ignore la diferencia entre el objeto compuesto y el objeto único, y que el usuario utilice todos los objetos en la estructura compuesta de manera uniforme.

Decorador

1. La intención
es agregar dinámicamente algunas responsabilidades adicionales a un objeto. El patrón Decorator es más flexible que la subclasificación en términos de agregar funcionalidad.

2. Estructura

• El componente define una interfaz de objeto que puede agregar dinámicamente responsabilidades a estos objetos.
• ConcreteComponent define un objeto al que se le pueden agregar algunas responsabilidades.
• El decorador mantiene un puntero al objeto Componente y define una interfaz consistente con la interfaz Componente.
• ConcreteDecorator agrega responsabilidades a los componentes.

3. Aplicabilidad

• Agregue responsabilidades a objetos individuales de forma dinámica y transparente sin afectar a otros objetos.
• Manejar aquellas responsabilidades que sean revocables.
• Cuando no se puede extender generando subclases. En un caso, puede haber una gran cantidad de extensiones independientes,
  y cada combinación generará una gran cantidad de subclases, lo que hará que la cantidad de subclases crezca de manera explosiva. Otra situación podría ser que la definición de clase esté oculta o no se pueda usar para generar subclases.

Fachada (apariencia)

1. La intención es
proporcionar una interfaz consistente para un conjunto de interfaces en el subsistema El patrón Facade define una interfaz de alto nivel que hace que el subsistema sea más fácil de usar.
2. Estructura

• Facade sabe qué clases de subsistemas son responsables de manejar las solicitudes; envía la solicitud del cliente al objeto del subsistema apropiado.
• Las clases del subsistema implementan las funciones del subsistema; procesan las tareas asignadas por el objeto Fachada; no hay información relevante sobre la Fachada, es decir, no hay un puntero a la Fachada.

3. Aplicabilidad

• Cuando se intenta proporcionar una interfaz simple para un subsistema complejo, el subsistema a menudo se vuelve más y más complejo debido a la evolución continua. La mayoría de los patrones producen más clases y más pequeñas cuando se usan, lo que hace que el subsistema sea más reutilizable y más fácil de personalizar, pero también brinda cierta facilidad de uso a los usuarios que no necesitan personalizar el subsistema. Facade puede proporcionar una vista predeterminada simple, que es suficiente para la mayoría de los usuarios, y aquellos que necesitan más personalización pueden omitir la capa Facade.
• Existe una gran dependencia entre el programa cliente y la parte de implementación de la clase abstracta. La introducción de Facade para separar este subsistema de los clientes y otros subsistemas puede mejorar la independencia y portabilidad del subsistema.
• Cuando necesite construir un subsistema jerárquico, use el patrón Fachada para definir los puntos de entrada para cada capa en el subsistema. Si los subsistemas son interdependientes, puede dejar que se comuniquen solo a través de la fachada, simplificando así las dependencias entre ellos.

peso mosca

1. Intención
Usar tecnología de uso compartido para admitir de manera efectiva una gran cantidad de objetos de granularidad fina.

2. Estructura

• Flyweight describe una interfaz a través de la cual Flyweight puede aceptar y actuar sobre estados externos.
• ConcreteFlyweight implementa la interfaz Flyweight y agrega almacenamiento para el estado interno (si lo hay).
• Los objetos ConcreteFlyweight deben poder compartirse. El estado que almacena debe ser interno, es decir, debe ser independiente de la escena del objeto ConcreteFlyweight.
• No es necesario compartir todas las subclases de Flyweight. La interfaz Flyweight permite compartir, pero no
  lo impone. Los objetos UnsharedConcreteFlyweight suelen tener objetos ConcreteFlyweight como elementos secundarios en algún nivel de la estructura del objeto Flyweight.
• FlyweightFactory crea y administra objetos Flyweight; para garantizar que los Flyweight se compartan de manera razonable, cuando un usuario solicita un Flyweight, el objeto FlyweightFactory proporciona una instancia creada o crea una instancia si no existe.
• El cliente mantiene una referencia a Flyweight; calcula o almacena el estado externo de uno o más Flyweights.

3. Aplicabilidad

• Una aplicación utiliza una gran cantidad de objetos.
• Se debe enteramente al uso de una gran cantidad de objetos, lo que genera una gran sobrecarga de almacenamiento. La mayoría de los estados de un objeto pueden convertirse en estados externos.
• Si elimina el estado externo de los objetos, puede reemplazar muchos grupos de objetos con relativamente pocos objetos compartidos.
• Las aplicaciones no dependen de la identidad del objeto. Dado que los objetos Flyweight se pueden compartir, la prueba de identidad devolverá verdadero para objetos conceptualmente distintos.

Apoderado

1. Destinado
a proporcionar un proxy para que otros objetos controlen el acceso a este objeto

2. Estructura

• El proxy guarda una referencia para que el proxy pueda acceder a la entidad; proporciona una interfaz idéntica a la interfaz del Sujeto, de modo que se puede usar el proxy en lugar de la entidad; controla el acceso a la entidad y puede ser responsable de crearla y eliminarla; otras funciones dependen del tipo de proxy: Remote Proxy es responsable de codificar la solicitud y sus parámetros, y de enviar la solicitud codificada a entidades en diferentes espacios de direcciones; Virtual Proxy puede almacenar en caché información adicional de entidades para retrasar el acceso a ella; Protection Proxy comprueba si la persona que llama tiene la implementación Un permiso de acceso requerido para una solicitud.
• Asunto define la interfaz compartida de RealSubject y Proxy, de modo que Proxy se puede usar donde sea que se use RealSubject.
• RealSubject define la entidad representada por el Proxy.

3. Aplicabilidad

• El proxy remoto (Remote Proxy) proporciona representación local para un objeto en diferentes espacios de direcciones.
• Virtual Proxy (Proxy virtual) crea objetos caros bajo demanda.
• Un proxy de protección controla el acceso al objeto original y se utiliza cuando el objeto debe tener diferentes derechos de acceso.
• Las referencias inteligentes reemplazan los punteros simples y realizan operaciones adicionales al acceder a los objetos. Los usos típicos incluyen: contar referencias a objetos reales para que se liberen automáticamente cuando no haya referencias a ellos; cargar un objeto persistente en la memoria cuando se hace referencia a él por primera vez; verificar si se ha bloqueado para asegurarse de que otros objetos no puedan cambiarlo.

Patrones de diseño de comportamiento

Cadena de responsabilidad

1. La intención
es permitir que múltiples objetos tengan la oportunidad de procesar la solicitud, evitando así la relación de acoplamiento entre el remitente y el receptor de la solicitud. Vincule estos objetos en una cadena y pase la solicitud a lo largo de la cadena hasta que un objeto la maneje.

2. Estructura

• Handler define una interfaz para procesar solicitudes; implementa la cadena sucesora.
• El ConcreteHandler maneja la solicitud de la que es responsable; tiene acceso a sus sucesores; si puede manejar la solicitud, la procesa, de lo contrario, reenvía la solicitud al sucesor.
• El cliente envía una solicitud al objeto controlador específico (ConcreteHandler) en la cadena.

3. Aplicabilidad

• Hay varios objetos que pueden manejar una solicitud, y qué objeto maneja la solicitud se determina automáticamente en tiempo de ejecución.
• Desea enviar una solicitud a uno de varios objetos sin especificar explícitamente el destinatario.
• El conjunto de objetos que pueden manejar una solicitud se especificará dinámicamente.

Dominio

1. La intención
es encapsular una solicitud como un objeto, de modo que el cliente pueda parametrizarse con diferentes solicitudes, poner en cola la solicitud o registrar la fecha de la solicitud y admitir operaciones que se pueden deshacer.

2. Estructura

• El comando declara la interfaz para realizar operaciones.
• ConcreteCommand vincula un objeto receptor a una acción; llama a la operación correspondiente del receptor para implementar Ejecutar
• El cliente crea un objeto de comando específico y establece su receptor
• El invocador le pide al comando que ejecute la solicitud
• El receptor sabe cómo implementar y realizar operaciones relacionadas con una solicitud, cualquier clase puede ser un receptor

3. Aplicabilidad

• Abstrae la acción a realizar para parametrizar un objeto. El patrón Command es un reemplazo orientado a objetos para el mecanismo de devolución de llamada (Callback) en lenguajes de procedimiento.
• Las solicitudes se especifican, se ponen en cola y se ejecutan en diferentes momentos. Un objeto Command puede tener una duración independiente de la solicitud original. Si el destinatario de una solicitud se puede expresar de manera independiente del espacio de direcciones, entonces el objeto de comando responsable de la solicitud se puede pasar a un proceso diferente y cumplir la solicitud allí.

Intérprete

1. Intención
Dado un idioma, definir una representación de su gramática y definir un intérprete que use esta representación para interpretar oraciones en el idioma.

2. Estructura

• AbstractExpression declara la operación de interpretación de un programa, y ​​esta interfaz es compartida por todos los nodos en el árbol de sintaxis abstracta.
• TerminalExpression implementa las operaciones de interpretación asociadas con terminales en una gramática; cada terminal en una oración requiere una instancia de esta clase.
• NonterminalExpression requiere una clase NonterminalExpression para cada regla de la gramática; mantiene una variable de instancia de tipo AbstractExpression para cada símbolo; implementa operaciones de interpretación para símbolos no terminales en la gramática.
• El contexto contiene información global fuera del intérprete.
• El cliente construye (o recibe) un árbol de sintaxis abstracta que representa una oración específica en el lenguaje definido por la gramática, ensamblada a partir de instancias de NonterminalExpression y TerminalExpression; invoca la operación de interpretación.

3. Aplicabilidad
El modo Intérprete es aplicable cuando hay un idioma que necesita ser interpretado y ejecutado, y las oraciones en el idioma se pueden representar como un árbol de sintaxis abstracta.Las siguientes situaciones funcionan mejor:

• La gramática es simple. Para publicaciones complejas, la jerarquía de clases de la gramática se vuelve inmanejablemente grande. Una herramienta como un generador de analizador es una mejor opción en este caso. Interpretan expresiones sin construir un árbol de sintaxis abstracta, lo que ahorra espacio y posiblemente tiempo.
• La eficiencia no es un tema crítico. Los intérpretes más eficientes generalmente no se logran interpretando árboles de análisis directamente, sino convirtiéndolos primero a otra forma. Sin embargo, incluso en este caso, el convertidor aún puede implementarse utilizando este modo.

iterador

1. Intención
Proporcionar un método para acceder secuencialmente a cada elemento en un objeto agregado sin exponer la representación interna del objeto.

2. Estructura

• Iterator define una interfaz para acceder y atravesar elementos.
• ConcreteIterator (iterador concreto) implementa la interfaz del iterador; rastrea la posición actual al atravesar el agregado
• Aggregate define la interfaz para crear objetos iteradores correspondientes.
• ConcreteAggregate (agregación concreta) implementa la interfaz para crear iteradores correspondientes y la operación devuelve una instancia apropiada de Concretelterator.

3. Aplicabilidad
El modo Iterador es adecuado para:

• Acceda al contenido de un objeto agregado sin exponer su representación interna.
• Admite múltiples recorridos de objetos agregados.
• Proporcione una interfaz unificada para atravesar diferentes estructuras de agregación.

Mediador

1. Intención
Usar un objeto intermediario para encapsular una serie de interacciones de objetos. Los mediadores eliminan la necesidad de que los objetos se refieran explícitamente entre sí, lo que los hace poco acoplados y sus interacciones se pueden cambiar de forma independiente.

2. Estructura

• Mediator (mediador) define una interfaz para cada colega (Colega) objeto de comunicación.
• ConcreteMediator (mediador concreto) realiza un comportamiento colaborativo coordinando el objeto de cada colega; comprende y mantiene a sus colegas.
• La clase Colleague (clase colega) conoce su objeto mediador, cada objeto clase colega se comunica con su mediador cuando necesita comunicarse con otros compañeros.

3. Aplicabilidad

• Un conjunto de objetos se comunica de una manera bien definida pero compleja, lo que da como resultado interdependencias que no están estructuradas y son difíciles de entender.
• Un objeto hace referencia y se comunica directamente con muchos otros objetos, lo que dificulta su reutilización.
• Desea personalizar un comportamiento que se distribuye en varias clases sin generar demasiadas subclases.

Recuerdo

1. La intención
es capturar el estado interno de un objeto sin romper la encapsulación y guardar este estado fuera del objeto. Esto le permite restaurar más tarde el objeto a su estado guardado anteriormente.

2. Estructura

• Memento (memorandum) almacena el estado interno del objeto originador, y el originador decide qué estado interno del originador almacena el memento según las necesidades; evita que otros objetos que no sean el originador accedan al memento.
• El originador crea una nota para registrar su estado interno en el momento actual; use la nota para restaurar el estado interno.
• El cuidador (gerente) es responsable de mantener el memorándum; no puede operar ni verificar el contenido del memorándum.

3. Aplicabilidad

• El estado (parcial) de un objeto en un momento determinado debe guardarse para que pueda restaurarse a un estado anterior cuando sea necesario más adelante.
• Si uno usa una interfaz para permitir que otros objetos obtengan estos estados directamente, expondrá los detalles de implementación del objeto y romperá la encapsulación del objeto.

Observador

1. Intención
Defina una relación de dependencia de uno a muchos entre objetos. Cuando cambia el estado de un objeto, todos los objetos que dependen de él serán notificados y actualizados automáticamente.

2. Estructura

• El sujeto (objetivo) conoce a sus observadores, y puede haber cualquier número de observadores observando el mismo objetivo; proporciona una interfaz para registrar y eliminar objetos de observador.
• Observer (observador) define una interfaz de actualización para los objetos que necesitan ser notificados cuando cambia el objetivo.
• ConcreteSubject (objetivo específico) almacena el estado relevante en cada objeto ConcreteObserver; cuando cambia su estado, envía una notificación a sus observadores.
• ConcreteObserver (observador específico) mantiene una referencia al objeto ConcreteSubject; almacena estados relevantes, que deben ser consistentes con el estado del objetivo; implementa la interfaz de actualización del Observer para mantener su propio estado consistente con el estado del objetivo.

3. Aplicabilidad

• Cuando un modelo abstracto tiene dos aspectos, uno de los cuales depende del otro, encapsule ambos en objetos separados para que puedan cambiarse y reutilizarse de forma independiente.
• Cuando un cambio en un objeto requiere cambios en otros objetos al mismo tiempo y no se sabe exactamente cuántos objetos se deben cambiar.
• Cuando un objeto debe informar a otros objetos, pero no puede asumir quiénes son los otros objetos, no quiere que estos objetos estén estrechamente acoplados.

Estado

1. Intención
Permite que un objeto cambie su comportamiento cuando cambia su estado interno. El objeto parece haber modificado su clase.

2. Estructura

• El contexto define las interfaces que interesan a los clientes; mantiene una instancia de la subclase ConcreteState que define el estado actual.
• State define una interfaz para encapsular el comportamiento asociado con un estado particular del contexto.
• ConcreteState (subclases de estado concreto) Cada subclase implementa comportamientos relacionados con un estado de Contexto.

3. Aplicabilidad

• El comportamiento de un objeto está determinado por su estado y debe cambiar su comportamiento de acuerdo con el estado en tiempo de ejecución.
• Una operación contiene una declaración condicional grande de varias ramas, y estas ramas dependen del estado del objeto. Este estado suele estar representado por una o más constantes de enumeración. A menudo, hay varias acciones que contienen esta misma estructura de casos. El patrón Estado pone cada rama condicional en una clase separada. Esto permite a los desarrolladores tratar el estado de un objeto como un objeto según sus propias condiciones, y este objeto puede cambiar de forma independiente sin depender de otros objetos.

Estrategia

1. Intención
Definir una serie de algoritmos, encapsularlos uno por uno y hacerlos intercambiables. Este modo permite que los algoritmos varíen independientemente de los clientes que los utilicen.

2. Estructura

• La estrategia define la interfaz común para todos los algoritmos admitidos. Context usa esta interfaz para llamar a un algoritmo definido por ConcreteStrategy.
• ConcreteStrategy (estrategia concreta) implementa un algoritmo específico con la interfaz de Estrategia.
• El contexto (context) se configura con un objeto ConcreteStrategy; mantiene una referencia al objeto Strategy; define una interfaz para que la estrategia acceda a sus datos.

3. Aplicabilidad

• Muchas clases relacionadas simplemente se comportan de manera diferente. Las estrategias proporcionan una forma de configurar una clase con uno de varios comportamientos.
• Es necesario utilizar diferentes variantes de un algoritmo. Por ejemplo, defina algunos algoritmos que reflejen las compensaciones de espacio/tiempo de diferentes espacios. El patrón de estrategia se puede utilizar cuando estas variantes se implementan como una jerarquía de clases para un algoritmo.
• Los algoritmos utilizan datos que los clientes no deberían conocer. El patrón de estrategia se puede utilizar para evitar exponer estructuras de datos complejas y dependientes de algoritmos.
• Una clase define una variedad de comportamientos, y estos comportamientos aparecen en forma de declaraciones condicionales múltiples en la operación de esta clase, y las ramas condicionales relevantes se mueven a sus respectivas clases de Estrategia para reemplazar estas declaraciones condicionales.

Método de plantilla

1. La intención
es definir el esqueleto de un algoritmo en una operación, mientras se transfieren algunos pasos a las subclases. Template Method permite que las subclases redefinan algunos pasos específicos de un algoritmo sin cambiar la estructura del algoritmo.

2. Estructura

• AbstractClass (clase abstracta) define operaciones primitivas abstractas, y las subclases específicas las redefinirán para implementar cada paso de un algoritmo; implemente un método de plantilla para determinar el esqueleto de un algoritmo, y el método de plantilla no solo llama a operaciones primitivas, sino que también llama a definiciones Operaciones en AbstractClass u otros objetos.
• ConcreteClass (clase concreta) implementa operaciones primitivas para completar los pasos en el algoritmo asociado con una subclase específica.

3. Aplicabilidad

• Implemente todas las partes inmutables de un algoritmo a la vez y deje el comportamiento variable a la clase.
• Los comportamientos que son comunes a todas las subclases deben extraerse y centralizarse en una clase principal común para evitar la duplicación de código.

Visitante

1. Intención
Indica una operación en cada elemento de una estructura de objeto. Permite definir nuevas operaciones sobre elementos sin cambiar su clase.

2. Estructura

• Visitor declara una operación Visit para cada clase de ConcreteElement en la estructura del objeto. El nombre y la firma de la operación identifican la clase que envió la solicitud de visita al visitante, lo que permite que el visitante determine la clase específica del elemento visitado. De esta forma el visitante puede acceder directamente a través de la interfaz específica del elemento.
• ConcreteVisitor (visitante concreto) implementa cada operación declarada por Visitor, cada operación implementa una parte del algoritmo, y el fragmento de algoritmo es la clase correspondiente al objeto en la estructura. ConcreteVisitor proporciona contexto para el algoritmo y almacena su estado local. Este estado a menudo acumula resultados durante el recorrido de la estructura.
• El elemento define una operación de aceptación que toma un visitante como parámetro.
• ConcreteElement (elemento concreto) implementa una operación de Aceptar que toma como parámetro a un visitante.
• ObjectStructure (estructura de objeto) puede enumerar sus elementos; puede proporcionar una interfaz de alto nivel para permitir que el visitante acceda a sus elementos; puede ser una combinación o una colección, como una lista o una colección desordenada.

3. Aplicabilidad

• Una estructura de objeto contiene muchos objetos de clase con diferentes interfaces, y los usuarios desean realizar algunas operaciones en estos objetos que dependen de sus clases específicas.
• Necesita realizar muchas operaciones diferentes y no relacionadas en objetos en una estructura de objeto, y quiere evitar que estas operaciones "contaminen" las clases de estos objetos. Visitor permite a los usuarios centralizar operaciones relacionadas y definirlas en una clase. Cuando la estructura del objeto es compartida por muchas aplicaciones, use el patrón Visitor para permitir que cada aplicación contenga solo las operaciones que deben usarse.
• Las clases que definen la estructura del objeto rara vez cambian, pero a menudo es necesario definir nuevas operaciones en esta estructura. Cambiar la clase de estructura del objeto requiere redefinir la interfaz para todos los visitantes, lo que puede resultar costoso. Si las clases de estructura de objetos cambian con frecuencia, puede ser mejor definir estas operaciones en esas clases.