Patrones de diseño de comportamiento by CARLOS EDUARDO RINCÓN GARCÍA

1. Definición

g2346014 — 2024-09-18 00:01:59 UTC

El cambio de responsabilidad implica la transferencia de tareas específicas de un componente a otro, lo que permite que cada clase o módulo del sistema cumpla con una única responsabilidad, mejorando la modularidad y la mantenibilidad del software. [1]

Ejemplo:

g2346014 — 2024-09-18 00:32:19 UTC

Referencias

g2346014 — 2024-09-18 00:40:15 UTC

[1] Martin, R. C. (2000). Design principles and design patterns. Object Mentor. https://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf

[2]

2. Relación con los Principios SOLID

g2346014 — 2024-09-18 00:47:13 UTC

Está profundamente vinculado con los siguientes principios SOLID:

¿Que es?

g2346015 — 2024-09-18 14:24:09 UTC

Principio de responsabilidad única (SRP)

g2346014 — 2024-09-18 18:48:19 UTC

A través este, las clases mantienen una única responsabilidad, evitando la sobrecarga y favoreciendo la claridad del código.

Principio Abierto/Cerrado (OCP)

g2346014 — 2024-09-18 18:48:57 UTC

También promueve el OCP, permitiendo que las clases sean extendibles sin modificar su comportamiento interno.

¿Qué es?

2024-09-18 18:54:38 UTC

El patrón Strategy es una forma de organizar el código para que podamos elegir entre diferentes maneras de hacer algo, sin tener que cambiar toda la estructura del programa. Es como tener una caja de herramientas con diferentes llaves: todas hacen algo similar (apretar tornillos), pero se usan en situaciones diferentes [1].

Ejemplo

2024-09-18 18:54:54 UTC

Imagina que tienes tres maneras de ir al parque:

Caminando.
En bicicleta.
En autobús.

Aunque las tres opciones te llevan al mismo lugar, cada una lo hace de forma diferente. Esto es como el patrón Strategy: diferentes estrategias para hacer lo mismo (llegar al parque), pero cada una se guarda en su propio lugar (clase) y se puede cambiar fácilmente.

2024-09-18 18:55:29 UTC

¿Cómo Funciona el Patrón Strategy?

2024-09-18 18:56:07 UTC

Contexto: Es la parte que decide qué estrategia utilizar (¿Caminar, bicicleta o autobús?).
Estrategias: Cada una de las maneras de hacer algo. Por ejemplo, caminar sería una estrategia, y montar en bicicleta sería otra.
Cliente: Es quien decide cuál estrategia usar. Por ejemplo, dependiendo del tiempo que tengas o de si hay autobuses, eliges una estrategia para ir al parque.

Puntos a favor:

2024-09-18 18:56:39 UTC

Cambio fácil de comportamiento

Código más limpio y organizado

Fácil de agregar nuevas estrategias

2024-09-18 18:57:30 UTC

¿Qué es?

2024-09-18 18:58:07 UTC

El Template Method es un patrón de diseño de comportamiento que permite definir los pasos de un algoritmo en una clase base, dejando que las clases derivadas modifiquen ciertos pasos sin cambiar la estructura general [1].

Ejemplo

2024-09-18 18:58:21 UTC

Imagina que estás haciendo un sándwich. Sabes que siempre necesitas hacer ciertos pasos como poner el pan, los ingredientes, y cerrar el sándwich. Pero, tal vez quieres cambiar los ingredientes, o el tipo de pan. El Template Method te permite seguir el "esqueleto" de cómo hacer un sándwich, pero puedes elegir tus propios ingredientes.

2024-09-18 18:58:30 UTC

2024-09-18 18:58:54 UTC

Puntos a favor

2024-09-18 18:59:16 UTC

Reutilización

Flexibilidad

¿Cómo funciona el Patrón Template method?

2024-09-18 19:02:28 UTC

Clase Base: Define el proceso general con un método que sigue varios pasos.
Métodos Fijos y Personalizables: Algunos pasos ya están definidos, mientras que otros se dejan como vacíos o abstractos para que las subclases los definan.
Subclases: Las subclases modifican solo los pasos necesarios sin cambiar el proceso completo.
Estructura Inmutable: El proceso general no cambia, solo los detalles.

Referencias

2024-09-18 19:05:12 UTC

[1] FOP Olga Skobeleva, «Strategy», Refactoring. Disponible en: https://refactoring.guru/es/design-patterns/strategy

Referencias

2024-09-18 19:05:49 UTC

[1] FOP Olga Skobeleva, «Themplate Method», Refactoring. Disponible en: https://refactoring.guru/es/design-patterns/template-method

¿Qué es?

2024-09-18 19:20:12 UTC

El patrón Visitor es un patrón de diseño de comportamiento que permite separar algoritmos (o comportamientos) de los objetos sobre los que operan. Esto significa que puedes añadir nuevas operaciones a una estructura de objetos sin modificar las clases de esos objetos [1].

Ejemplo

2024-09-18 19:20:26 UTC

Imagina un agente de seguros que visita diferentes tipos de edificios y ofrece seguros específicos según el tipo de edificio. El agente (Visitor) sabe qué ofrecer basándose en el tipo de edificio (Element).

2024-09-18 19:20:34 UTC

¿Cómo funciona?

2024-09-18 19:21:15 UTC

Visitor (Visitante): Define qué hacer con cada tipo de objeto.
Element (Elemento): Los objetos aceptan al visitante y permiten que haga su trabajo.
ConcreteVisitor (Visitante Concreto): Implementa las operaciones específicas para cada tipo de objeto.

Referencias

2024-09-18 19:27:03 UTC

[1] FOP Olga Skobeleva, «Visitor», Refactoring. Disponible en: https://refactoring.guru/es/design-patterns/visitor

g2346014 — 2024-09-18 21:22:42 UTC

Patrón de Delegación
Consiste en que un objeto delega la responsabilidad de ejecutar una operación a otro objeto. Es esencial para implementar la separación de responsabilidades, ya que permite que un objeto principal gestione tareas sin tener que ejecutarlas por sí mismo.

g2346014 — 2024-09-18 21:34:41 UTC

Patrón Cadena de Responsabilidad
Permite que una solicitud pase a través de una cadena de manejadores. Cada manejador tiene la oportunidad de procesar la solicitud o pasarla al siguiente en la cadena. Es útil cuando se necesita delegar la responsabilidad del manejo de una tarea a múltiples objetos.

g2346014 — 2024-09-18 21:35:00 UTC

Patrón Estrategia
Permite que un objeto cambie su comportamiento en tiempo de ejecución, delegando la responsabilidad de un algoritmo específico a una clase concreta de estrategia.

g2346014 — 2024-09-18 21:35:01 UTC

Patrón Comando
Encapsula una solicitud como un objeto, permitiendo la delegación del procesamiento de esa solicitud a diferentes manejadores o receptores.

3. Patrones de diseño que aplican el cambio de responsabilidad:

g2346014 — 2024-09-18 21:37:14 UTC

4. Beneficios del cambio de responsabilidad

g2346014 — 2024-09-19 04:42:37 UTC

Tiene varios beneficios importantes:

Modularidad y mantenibilidad

g2346014 — 2024-09-19 04:44:09 UTC

Al distribuir las responsabilidades adecuadamente, se obtiene un sistema modular donde las clases tienen funciones específicas, lo que facilita la mantenibilidad del código.

Reutilización de Código

g2346014 — 2024-09-19 04:44:42 UTC

Las clases especializadas permiten que partes del código se puedan reutilizar en otros contextos, promoviendo la eficiencia en el desarrollo.

Flexibilidad y Escalabilidad

g2346014 — 2024-09-19 04:45:04 UTC

Permite que el sistema sea más flexible, ya que los cambios pueden implementarse sin afectar otros componentes.

5. Ejemplo práctico

g2346014 — 2024-09-19 04:48:05 UTC

Java: Implementación del Patrón Estrategia

g2346014 — 2024-09-19 04:49:18 UTC

El patrón estrategia se implementa creando una interfaz común para los algoritmos (estrategias) y permitiendo que la clase principal delegue el comportamiento a diferentes implementaciones de la estrategia. Esto facilita la extensión del comportamiento sin modificar el código existente.

6. Casos de uso

g2346014 — 2024-09-19 05:00:51 UTC

g2346014 — 2024-09-19 05:01:26 UTC

Aplicaciones de escritorio
En aplicaciones con interfaces gráficas, el patrón comando es comúnmente utilizado para delegar la responsabilidad de las interacciones del usuario a diferentes componentes, facilitando la organización del código y la implementación de nuevas funcionalidades.

g2346014 — 2024-09-19 05:02:13 UTC

Aplicaciones web
En frameworks como Spring para Java, el patrón de estrategia se utiliza para delegar la lógica de negocio a diferentes servicios, manteniendo la separación de preocupaciones y mejorando la modularidad.

7. Retos potenciales

g2346014 — 2024-09-19 05:13:27 UTC

g2346014 — 2024-09-19 05:14:07 UTC

Aunque el cambio de responsabilidad tiene muchas ventajas, también puede aumentar la complejidad del sistema si no se maneja adecuadamente. En sistemas muy grandes, el exceso de delegación puede generar dependencias circulares o dificultar la depuración del código.

8. Patrones Relacionados

g2346014 — 2024-09-19 05:14:40 UTC

Patrón mediador

g2346014 — 2024-09-19 05:15:33 UTC

Este patrón permite centralizar la comunicación entre diferentes objetos, reduciendo la complejidad y evitando dependencias directas entre ellos. El cambio de responsabilidad aquí es evidente, ya que se transfiere la lógica de comunicación a una clase mediadora.

g2346015 — 2024-09-19 05:16:13 UTC

El patrón de diseño Iterator permite recorrer secuencialmente los elementos de una colección sin exponer su representación interna. Facilita la implementación de colecciones iterables y la separación entre las estructuras de datos y los algoritmos que operan sobre ellas [1].

9. Implementación en frameworks y tecnologías modernas

g2346014 — 2024-09-19 05:16:18 UTC

g2346014 — 2024-09-19 05:16:43 UTC

Frameworks como Spring en Java y Django en Python implementan el cambio de responsabilidad mediante la inyección de dependencias, lo que permite una gestión eficiente de los servicios y la lógica de negocio. Esto facilita la reutilización de componentes y la modificación de funcionalidades sin afectar el sistema general

Referencias

g2346015 — 2024-09-19 05:17:34 UTC

[3] G. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994, pp. 305-313.

g2346015 — 2024-09-19 05:18:25 UTC

Las colecciones son uno de los tipos de datos más utilizados en programación. No obstante, una colección es sólo un contenedor para un grupo de objetos.

La mayoría de las colecciones almacenan sus elementos en listas simples. Sin embargo, algunos de ellos se basan en pilas, árboles, gráficos y otras estructuras de datos complejas.

Pero no importa cómo esté estructurada una colección, debe proporcionar alguna forma de acceder a sus elementos para que otro código pueda utilizarlos. Debería haber una manera de revisar cada elemento de la colección sin acceder a los mismos elementos una y otra vez.

Esto puede parecer un trabajo fácil si tiene una colección basada en una lista. Simplemente recorre todo los elementos. Pero, ¿cómo se atraviesan secuencial-mente elementos de una estructura de datos compleja, como un árbol? Por ejemplo un día podría estar bien con el recorrido de un árbol en profundidad. Sin embargo, al día siguiente es posible que necesite un recorrido en amplitud. Y la próxima semana, es posible que necesites algo mas, como acceso aleatorio a los elementos del árbol.

g2346015 — 2024-09-19 05:19:21 UTC

La idea principal del patrón iterador es extraer el comportamiento transversal de una colección en un objeto separado llamado iterador.

Además de implementar el algoritmo en sí, un objeto iterador encapsula todos los detalles de recorrido, como la posición actual y cuántos elementos quedan hasta el final. Debido a esto, varios iteradores pueden recorrer la misma colección al mismo tiempo, independientemente unos de otros.

g2346015 — 2024-09-19 05:22:44 UTC

Imagina que tienes dos cajas de libros. Una de ellas está organizada de manera secuencial, con los libros ordenados por tema o autor, mientras que la otra está llena de libros colocados de forma completamente aleatoria. Si quieres encontrar un libro específico, o simplemente recorrer todos los libros de la caja, en la primera caja (organizada), sería sencillo pasar de un libro al siguiente en un orden lógico. En la caja desorganizada, necesitarías algún mecanismo para moverte entre los libros, porque no hay un orden establecido.

Aquí es donde entra el patrón Iterator: sin importar cómo estén organizados los libros (la estructura interna de la colección), el Iterator te permite recorrer cada libro de manera uniforme, asegurándose de que puedas acceder a cada uno sin preocuparte de cómo están almacenados.

Código (Typescript)

g2346015 — 2024-09-19 05:23:23 UTC

Ejemplo:

g2346014 — 2024-09-19 05:32:11 UTC

Imagina que en una oficina, el gerente de un proyecto tiene varias responsabilidades, como preparar informes, coordinar reuniones y gestionar presupuestos. Sin embargo, en lugar de hacer todo por sí mismo, el gerente delegará estas tareas a diferentes miembros de su equipo, quienes tienen habilidades especializadas para llevarlas a cabo.

Gerente: Actúa como el "controlador" que tiene el objetivo general.
Especialista en informes: Se encarga de la redacción y presentación de los informes.
Coordinador de reuniones: Organiza y coordina las reuniones necesarias.
Encargado de finanzas: Gestiona y revisa los presupuestos del proyecto.

Roles de ejemplo de código

g2346015 — 2024-09-19 05:35:34 UTC

Iterator (Interfaz Iterator): Iterator
Concrete Iterator (Iteradores concretos): LibrosIterator y RandomLibrosIterator
Collection (Colección abstracta): CajaDeLibros (aunque en este caso es la misma que la colección concreta)
Concrete Collection (Colección concreta): CajaDeLibros

g2346015 — 2024-09-19 05:36:19 UTC

¿Que es?

g2346015 — 2024-09-19 05:38:55 UTC

El patrón Memento es un patrón de diseño de comportamiento que permite capturar y almacenar el estado interno de un objeto sin violar su encapsulamiento, para que el objeto pueda volver a ese estado más tarde. Se utiliza para implementar funciones de deshacer o restaurar en aplicaciones [2].

¿Que error soluciona?

g2346015 — 2024-09-19 05:39:55 UTC

Imagina que estás creando una aplicación de edición de texto. Además de la edición de texto simple, su editor puede formatear el texto, insertar imágenes en línea, etc.

En algún momento, decidiste permitir a los usuarios deshacer cualquier operación realizada en el texto. Esta característica se ha vuelto tan común a lo largo de los años que hoy en día la gente espera que todas las aplicaciones la tengan. Para la implementación, optó por adoptar el enfoque directo. Antes de realizar cualquier operación, la aplicación registra el estado de todos los objetos y lo guarda en algún lugar de almacenamiento. Más tarde, cuando un usuario decide revertir una acción, la aplicación recupera la última instantánea del historial y la utiliza para restaurar el estado de todos los objetos.

¿Como lo soluciona?

g2346015 — 2024-09-19 05:43:28 UTC

El patrón sugiere almacenar la copia del estado del objeto en un objeto especial llamado memento. El contenido del memento no es accesible para ningún otro objeto, excepto para el que lo produjo. Otros objetos deben comunicarse con los mementos usando una interfaz limitada, que puede permitir acceder a meta datos de la instantánea (como el tiempo de creación, el nombre de la operación realizada, etc.), pero no al estado original que contiene la instantánea.

Analogía

g2346015 — 2024-09-19 05:49:12 UTC

El patrón Memento puede explicarse con la analogía del papel carbón. Imagina que estás escribiendo en una máquina de escribir y debajo de la hoja principal colocas una hoja con papel carbón. Cada vez que escribes, el papel carbón guarda una copia exacta de lo que has escrito, pero esa copia no puede ser modificada directamente. Si en algún momento quieres restaurar lo que habías escrito antes, puedes sacar esa copia del papel carbón y volver al estado anterior. En esta analogía, la máquina de escribir es el objeto que genera el estado (el texto escrito), el papel carbón es el Memento que guarda una copia del estado, y el cajón donde guardas esas copias de papel carbón es el Caretaker, que se encarga de almacenar y restaurar esos estados sin tener acceso directo al contenido que guardan. Esto permite deshacer cambios y restaurar estados anteriores sin romper el encapsulamiento del objeto.

Código (TypeScript)

g2346015 — 2024-09-19 05:51:03 UTC

Roles de ejemplo de código

g2346015 — 2024-09-19 05:56:58 UTC

Originador (Originator): MaquinaDeEscribir – el objeto que genera y guarda su propio estado.
Memento: Memento – almacena el estado del Originador en un momento específico.
Cuidador (Caretaker): Caretaker – guarda y administra los Mementos sin conocer su contenido.
Cliente (Client): El código de simulación que interactúa con el Originador y el Caretaker para guardar y restaurar estados.

¿Que es?

g2346015 — 2024-09-19 05:59:32 UTC

El patrón State es un patrón de diseño de comportamiento que permite a un objeto cambiar su comportamiento cuando su estado interno cambia. Desde el punto de vista del cliente, parece que el objeto cambia de clase. Este patrón es útil cuando un objeto debe cambiar su comportamiento dinámicamente dependiendo de su estado, evitando una gran cantidad de condicionales [3].

¿Que error soluciona?

g2346015 — 2024-09-19 06:06:13 UTC

El patrón State proporciona una solución al encapsular los comportamientos dependientes del estado en clases separadas, lo que permite que el objeto principal delegue las acciones a sus estados correspondientes. Esto elimina los condicionales extensos y facilita la adición de nuevos estados sin modificar el código existente. Un ejemplo clásico es un sistema de máquina de estados finitas, donde un objeto puede cambiar su comportamiento dinámicamente según su estado actual.

¿Como lo soluciona?

g2346015 — 2024-09-19 06:08:24 UTC

El patrón de estado sugiere crear nuevas clases para todos los estados posibles de un objeto y extraer todos los comportamientos específicos del estado en estas clases.

En lugar de implementar todos los comportamientos por sí mismo, el objeto original, llamado contexto, almacena una referencia a uno de los objetos de estado que representa su estado actual, y delega todo el trabajo relacionado con el estado a este objeto.

Diagrama

g2346015 — 2024-09-19 06:08:44 UTC

Diagrama

g2346015 — 2024-09-19 06:09:31 UTC

Analogía

g2346015 — 2024-09-19 06:14:25 UTC

Imagina un reproductor de música que tiene varios estados: bloqueado, reproduciendo y pausado. Cada estado tiene un comportamiento diferente cuando presionas los botones.

En el estado bloqueado, si presionas el botón de play, el reproductor no hará nada porque está bloqueado.
En el estado reproduciendo, si presionas el botón de play, el reproductor pausará la música.
En el estado pausado, si presionas el botón de play, el reproductor comenzará a reproducir la música nuevamente.

Código (TypeScript)

g2346015 — 2024-09-19 06:14:50 UTC

Roles de ejemplo de código

g2346015 — 2024-09-19 06:18:35 UTC

Document (Context): Corresponde a la clase MusicPlayer en el código, que es el objeto que delega el comportamiento a los estados y cambia su estado cuando es necesario.
State (Interfaz): Representa la interfaz State, que define los métodos que todos los estados deben implementar (play(), pause(), stop()).
Draft (Estado Concreto): En el código, esto corresponde a los estados concretos (PlayingState, PausedState, StoppedState), que implementan el comportamiento específico para cada estado del reproductor.

¿Que es?

g2346015 — 2024-09-19 06:19:24 UTC

El patrón Mediator es un patrón de diseño de comportamiento que facilita la comunicación entre varios objetos sin que estos interactúen directamente entre sí, reduciendo las dependencias entre ellos. En lugar de que los objetos se comuniquen directamente, lo hacen a través de un mediador central, que se encarga de coordinar las interacciones. Esto ayuda a que el sistema sea más flexible y manejable, permitiendo cambiar las interacciones entre objetos sin modificarlos directamente [4].

¿Que error soluciona?

g2346015 — 2024-09-19 06:20:53 UTC

Supongamos que tiene un cuadro de diálogo para crear y editar perfiles de clientes. Consta de varios controles de formulario, como campos de texto, casilla de verificación, botones, etc.

Algunos de los elementos del formulario pueden interactuar con otros. Por ejemplo, seleccionar la casilla "Tengo un perro" puede revelar un campo de texto oculto para ingresar el nombre del perro. Otro ejemplo es el botón de enviar que debe validar los valores de todos los campos antes de guardar los datos.

Los elementos pueden tener muchas relaciones con otros elementos. Por tanto, los cambios en algunos elementos pueden afectar a otros.

¿Como lo soluciona?

g2346015 — 2024-09-19 06:23:01 UTC

El patrón mediador sugiere que debe cesar toda comunicación directa entre los componentes que desea independizar entre sí. En cambio, estos componentes deben colaborar indirectamente, llamando a un objeto mediador especial que redirige las llamadas a los componentes apropiados. Como resultado, los componentes dependen sólo de una única clase mediadora en lugar de estar acoplados a decenas de sus de sus colegas.

Diagrama

g2346015 — 2024-09-19 06:23:40 UTC

Roles

g2346015 — 2024-09-19 06:26:12 UTC

Mediator Interface (Interfaz del Mediador): Mediador (define la interfaz notificar()).
Concrete Mediator (Mediador Concreto): DirectorDeOrquesta (coordina las interacciones entre los músicos).
Components (Componentes): Violinista, Pianista, Trompetista (los músicos que interactúan entre sí a través del mediador).
Client (Cliente): El código que instancia los componentes y el mediador, y comienza la secuencia de eventos.

1. Definición

g2346014 — 2024-09-19 16:32:09 UTC

1. Definición

g2346014 — 2024-09-19 16:32:37 UTC

Observer es un patrón de diseño de comportamiento que define una relación uno a muchos entre objetos, de manera que cuando un objeto cambia de estado, todos sus dependientes son notificados y actualizados automáticamente. Es comúnmente utilizado en sistemas donde diferentes componentes necesitan ser sincronizados sin estar fuertemente acoplados, como en sistemas de eventos o interfaces gráficas de usuario (GUI). [1]

Referencias

g2346014 — 2024-09-19 16:37:58 UTC

[4] G. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994, pp. 273-282.

Referencias

g2346014 — 2024-09-19 16:38:07 UTC

[2] G. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994, pp. 283-292.

Referencias

g2346014 — 2024-09-19 16:38:18 UTC

[1] G. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994, pp. 257-271.

[5] https://refactoring.guru/design-patterns

¿Que error soluciona?

g2346014 — 2024-09-19 16:41:18 UTC

¿Como lo soluciona?

g2346014 — 2024-09-19 16:41:34 UTC

Analogía

g2346014 — 2024-09-19 16:41:52 UTC

Diagrama

g2346014 — 2024-09-19 16:42:05 UTC

Ejemplo:

g2346014 — 2024-09-19 16:43:57 UTC

2. Relación con los principios SOLID

g2346014 — 2024-09-19 16:44:15 UTC

El patrón Observer respalda los principios SOLID:

g2346014 — 2024-09-19 16:44:31 UTC

Principio de Responsabilidad Única (SRP): Permite que los sujetos (objetos observados) se encarguen únicamente de actualizar su estado, delegando la responsabilidad de reacción en los observadores.

g2346014 — 2024-09-19 16:44:37 UTC

Principio de Inversión de Dependencias (DIP): Los observadores dependen de interfaces, no de implementaciones concretas, lo que permite que diferentes tipos de observadores respondan a cambios de estado. [2]

Ejemplo del Patrón Observer

g2346014 — 2024-09-19 16:44:44 UTC

4. Beneficios del observer:

g2346014 — 2024-09-19 16:45:22 UTC

5. Ejemplo práctico:

g2346014 — 2024-09-19 16:45:38 UTC

6. Desventajas del patrón observer:

g2346014 — 2024-09-19 16:45:58 UTC

7. Retos potenciales:

g2346014 — 2024-09-19 16:46:12 UTC

8. Patrones relacionados:

g2346014 — 2024-09-19 16:46:16 UTC

g2346014 — 2024-09-19 17:00:14 UTC

Un ejemplo típico es un sistema de notificaciones en el cual varios usuarios (observadores) reciben actualizaciones de un sistema central (sujeto). Cuando el sujeto cambia de estado (como un nuevo mensaje), todos los observadores registrados son notificados automáticamente.

g2346014 — 2024-09-19 17:16:51 UTC

Desacoplamiento: El sujeto y los observadores están desacoplados, lo que facilita la escalabilidad y el mantenimiento del sistema.
Extensibilidad: Se pueden agregar nuevos observadores sin modificar el código existente.
Flexibilidad en la notificación: Los observadores pueden registrarse y desregistrarse dinámicamente.

g2346014 — 2024-09-19 17:18:09 UTC

g2346014 — 2024-09-19 17:19:05 UTC

Puede introducir complejidad en aplicaciones grandes con muchos observadores, especialmente cuando se requiere un control sobre el orden de las notificaciones o cuando el ciclo de vida de los observadores no está claramente definido

g2346014 — 2024-09-19 17:19:50 UTC

Patrón Mediador: Ambos patrones separan las interacciones entre objetos. Sin embargo, el mediador centraliza las interacciones, mientras que el Observer notifica a los observadores de manera distribuida.
Patrón Event-Driven: Este patrón tiene una relación similar con Observer, ya que muchos sistemas de eventos utilizan la mecánica de observación para notificar a los oyentes cuando ocurre un evento.

g2346014 — 2024-09-19 17:20:25 UTC

El patrón Command encapsula una solicitud como un objeto, permitiendo parametrizar clientes con diferentes solicitudes, poner en cola o registrar solicitudes, y soportar operaciones que se puedan deshacer. En lugar de que el cliente invoque directamente una operación, la solicitud se envuelve en un comando que puede ser ejecutado, deshecho o repetido según sea necesario.

g2346014 — 2024-09-19 17:20:48 UTC

Principio Abierto/Cerrado (OCP): Nuevos comandos se pueden añadir sin modificar las clases existentes, lo que permite la extensión del sistema.

Relación con principios SOLID

g2346014 — 2024-09-19 17:21:02 UTC

El patrón Command se alinea bien con los principios SOLID:

g2346014 — 2024-09-19 17:21:30 UTC

Principio de Responsabilidad Única (SRP): Cada comando tiene la responsabilidad de ejecutar una sola operación.

Ejemplo del patrón command:

g2346014 — 2024-09-19 17:21:51 UTC

g2346014 — 2024-09-19 17:22:07 UTC

Un ejemplo común es en sistemas de interfaz de usuario, como un editor de texto. Cada acción del usuario (por ejemplo, copiar, cortar, pegar) se encapsula como un comando. Esto permite deshacer/rehacer acciones, almacenar comandos para su ejecución futura, y mantener un registro claro de las operaciones realizadas.

Beneficios del patrón command:

g2346014 — 2024-09-19 17:22:27 UTC

g2346014 — 2024-09-19 17:22:42 UTC

Desacoplamiento entre el emisor y el receptor: Los comandos permiten que el cliente esté desacoplado del receptor de la solicitud.
Soporte para deshacer y rehacer operaciones: Al almacenar un historial de comandos, el sistema puede revertir acciones o repetirlas.
Facilita la creación de colas de comandos: Los comandos se pueden almacenar en colas o listas para ser ejecutados en secuencia.

Desventajas del patrón command:

g2346014 — 2024-09-19 17:22:56 UTC

g2346014 — 2024-09-19 17:23:27 UTC

El patrón Command puede agregar complejidad innecesaria en sistemas donde las operaciones son simples y no requieren flexibilidad adicional. Además, mantener un historial de comandos para soportar la operación de deshacer puede consumir recursos si no se gestiona adecuadamente

Patrones relacionados:

g2346014 — 2024-09-19 17:23:47 UTC

g2346014 — 2024-09-19 17:24:01 UTC

Patrón Estrategia: Ambos patrones encapsulan comportamientos, pero Command se centra en encapsular una operación que será ejecutada, mientras que Estrategia encapsula un algoritmo.
Patrón Memento: Command y Memento pueden trabajar juntos para implementar deshacer y rehacer. Memento almacena el estado anterior del sistema, mientras que Command encapsula las acciones.

Referencias

g2346014 — 2024-09-19 17:24:23 UTC

[2] Fowler, M. (2004). Patterns of enterprise application architecture. Addison-Wesley.

[3] Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.

Referencias

g2346014 — 2024-09-19 17:24:31 UTC

[1] Fowler, M. (2004). Patterns of enterprise application architecture. Addison-Wesley.

[2] Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.

g2346014 — 2024-09-19 18:00:23 UTC

Observable: Es el objeto que está siendo observado. Puede haber cambios de estado en este objeto que son importantes para otros objetos.
ObserverA y ObserverB: Son los objetos observadores que se suscriben al objeto observable para ser notificados cuando ocurra un cambio de estado en él.