# Patrones de Diseño #### 1. **Patrón Strategy** * **Por qué:** Permite encapsular diferentes algoritmos en clases independientes. En el caso del microservicio de Booking, se pueden tener múltiples estrategias para procesar datos de reservas provenientes de distintas APIs. El patrón Strategy permitiría seleccionar y aplicar la estrategia adecuada en tiempo de ejecución según la API desde la cual proviene el dato. * **Ventaja:** Facilita la extensión del sistema al permitir la adición de nuevas estrategias de procesamiento sin necesidad de modificar el código existente. Esto es útil para manejar diferentes formatos de datos o lógica de negocio específica para cada API. #### **2. Patrón Adapter** * **Por qué:** Permite convertir la interfaz de una clase en otra interfaz que el cliente espera. Esto es especialmente útil cuando se integra el microservicio con APIs externas que tienen formatos de datos incompatibles. El patrón Adapter puede transformar datos de una API externa para que se ajusten a la interfaz que el microservicio espera. * **Ventaja:** Permite integrar componentes con interfaces incompatibles de manera transparente, sin modificar el código del cliente que utiliza estas interfaces. #### **3. Patrón Facade** * **Por qué:** Proporciona una interfaz unificada para un conjunto de interfaces en un subsistema. En el microservicio de Booking, puede simplificar la interacción con múltiples APIs (BookingAPI, FixtureAPI) al proporcionar una única interfaz que abstrae la complejidad de las interacciones con estas APIs. * **Ventaja:** Facilita el uso del subsistema al ocultar la complejidad de las interacciones con múltiples APIs, ofreciendo una interfaz más sencilla y cohesiva para los usuarios del microservicio. #### **4. Patrón Singleton** * **Por qué:** Asegura que una clase tenga una única instancia y proporciona un punto de acceso global a esa instancia. En el microservicio de Booking, puede utilizarse para gestionar una única instancia de conexión a una base de datos o a servicios externos, garantizando la consistencia y el control centralizado. * **Ventaja:** Previene la creación de múltiples instancias de una clase, lo que es útil para gestionar recursos compartidos como conexiones a bases de datos, evitando problemas de sincronización y consumo innecesario de recursos. #### **5. Patrón Observer** * **Por qué:** Permite que un objeto notifique a otros objetos sobre cambios en su estado. En el contexto del microservicio de Booking, puede utilizarse para notificar a diferentes componentes del sistema sobre eventos de reservas o actualizaciones en tiempo real, como cambios en el estado de una reserva. * **Ventaja:** Facilita la comunicación entre objetos sin necesidad de que estos estén directamente acoplados, permitiendo una mayor flexibilidad y escalabilidad en la gestión de eventos y actualizaciones. #### **6. Patrón Command** * **Por qué:** Encapsula una solicitud como un objeto, permitiendo parametrizar clientes con diferentes solicitudes y soportar operaciones deshacer y rehacer. En el microservicio de Booking, puede utilizarse para encapsular comandos relacionados con la gestión de reservas, como crear, actualizar o cancelar reservas. * **Ventaja:** Permite una mayor flexibilidad en la ejecución de operaciones, facilita la implementación de operaciones deshacer/rehacer y soporta la ejecución de comandos de manera desacoplada. #### **7. Patrón Proxy** * **Por qué:** Proporciona un sustituto o representante de otro objeto para controlar el acceso a este. En el microservicio de Booking, se puede usar un proxy para gestionar el acceso a servicios externos o cachés, controlando y optimizando las solicitudes a APIs externas y gestionando aspectos como la autenticación o el almacenamiento en caché. * **Ventaja:** Permite un control adicional sobre el acceso a un objeto, optimiza el acceso a recursos externos y puede proporcionar funcionalidades adicionales como caching y lazy loading. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs-affiliates.inlaze.com/gaming-docs/architecture/sistema-de-sportsbook/estructura/booking/patrones-de-diseno.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.