Integrantes
- Juan Diego Rodriguez Velasquez
- Ignacio Andres Castillo Rendon
- Anderson Fabian Garcia Nieto
Nombre de la rama
feature/CastilloIgnacio_GarciaAnderson_RodriguezDiego_2025-2
Evidencia Codigo y requisitos
Evidencia Solución
Para el diseño se utilizó los princios solid como base, usamos clases pequeñas y enfocadas en cumplir una tarea, product y cartItem encapsulan datos del funcionamiento interno, shopping cart agrega los items y calcula el subtotal utilizando streams, maps y tambien utiliza la interfaz DiscountPolicy que a su vez refleja el poliformismo al aplicar distintos descuentos dependiendo del tipo de cliente que sea, Recipt se enfoca en la construcción del recibo, Reto1 se comporta como nuestro main coordinando la interaccion entre clases y entradas de datos, por ultimo Money permite un formato adecuado para el dinero.
Elegimos trabajar de esra forma debido a que cumple los requisitos del reto, cumple los principios SOLID, pensado para que las clases sirvan de forma independiente y pueda ser facilmente extendido, se puede manejar distintos tipos de productos o extenderse para ser utilizado dentro de un sistema más complejo.
Permite un flujo directo, el usuario ingresa, registra que tipo de usuario es, elige sus compras, son validaddas, y finalmente se genera un recibo en el que se pueden ver los resultados con claridad.
Evidencia Codigo Implementado
Evidencia Solución
Implementamos el patrón creacional para construir la hamburguesa paso a paso a partir de ingredientes opcionales, se abstrae Ingredient con getters, sobre el se apoyan los ingredientes predefinidos y del usuario, la hamburguesa encapsula ingredientes y expone el precio total. El chef, orquesta el proceso con su metodo para crear hamburguesa, el BurguerBuilder junta los ingredientes y retorna la hamburguesa, finalmente usamos como principal Reto2BurguerBuilder quien gestiona todo el inicio y funcionamiento del reto.
El patrón creacional nos permite crear este producto instanciando ingredientes, que pueden llegar a variar y al final de cuentas tal como en la vida real la hamburguesa está compuesta de otros objetos más pequeños, por lo que es el que más sentido tiene implementar.
Implementamos las distintas clases y empezamos un flujo como se muestra en el ejemplo, permitiendo el facil uso de la misma, mostramos los ingredientes predefinidos, permitimos la seleccion de ingredientes predefinidos y posteriormente agregar ingredientes personalizados, para finalmente retornar la lista de ingredientes junto al precio total; más en terminos de codigo, el usuario ingresa numeros separados por coma para seleccionar opciones, luego ingresa el ingrediente personalizado que es normalizado por el runner, crea el nuevo ingrediente, y construye una lista con ingredientes, el chef recibe los ingredientes y empieza a crea la hamburguesa haciendo uso del burguerbuilder, la burguer creada calcula su valor total y devuelve la cadena de ingredientes junto a su valor para generar la impresión final.
Evidencia Codigo y requisitos
Evidencia Solución
Para este código se implementó el patrón creacional, específicamente el Abstract Factory, debido a que se tiene diferentes tipos de vehículos (terrestres, aéreos y acuáticos) al igual que las diferentes categorías(lujoso, económico, usado). Se diseñaron clases que cumplen sus respectivas responsabilidades:
- QualityCategory y sus "hijas" (Economic, Luxury, UsedCategory) encapsulan la lógica de cada tipo de categoría de vehículo, aplicando multiplicadores para precio, velocidad y comodidad.
- Vehicle representa la instancia final del producto, combinando las características del tipo de vehículo y la categoría elegida por el usuario.
- VehicleFactory y sus implementaciones (EconomicVehicleFactory, LuxuryVehicleFactory, UsedVehicleFactory) permiten crear vehículos concretos sin que el cliente conozca la lógica interna.
- VehicleSpecification y VehicleSpecificationRepository centralizan los datos base de cada modelo (velocidad, precio, equipamiento), generando la separación de responsabilidades.
- VehicleKingdomSystem actúa como la clase principal, la que se encarga de la interacción con el usuario y el cálculo de los totales.
Se elige ese patrón debido a que el problema requiere la creación de familias de objetos relacionados (vehículos en distintas categorías). Y a razón de eso, cada categoría cambia comportamientos como comodidad, precio y equipamiento, por lo cual era necesario desacoplar la lógica de creación de la lógica de uso.
El flujo inicia cuando el usuario entra al sistema (VehicleKingdomSystem), selecciona el tipo de transporte (terrestre, acuático o aéreo), la categoría (económico, lujo, usado) y finalmente el modelo específico. El sistema utiliza la fábrica adecuada para crear el vehículo con las características correspondientes. El usuario puede agregar múltiples vehículos, y al finalizar se muestra un resumen detallado con especificaciones y precios. El cálculo del total se realiza mediante Streams, asegurando claridad y eficiencia en el manejo de colecciones.
Evidencia Codigo y requisitos
Evidencia Solución
Se utiliza el patrón strategy, dentro de la categoría de patrones de comportamiento. La solución implementada se organiza en clases cada una con una responsabilidad definida:
- Currency define las monedas como un enum, con nombre, símbolo y código.
- ExchangeStrategy es la interfaz que define las operaciones de conversión y obtenció de tasas de cambio.
- RealExchangeStrategy implementa la interfaz, simulando tasas de cambio reales y centraliza la lógica de conversión.
- CurrencyExchanger actúa como el contexto del patrón Strategy, delegando el cálculo a la estrategia seleccionada, permitiendo el intercambio fácilmente.
- ExchangeTransaction y CurrencyConversion encapsulan los datos de las transacciones, guardando la información de origen, destino, monto y tasas aplicadas.
- CurrencyExchangeSystem es la clase que se encarfa de la interacción con el usuario, gestiona las transacciones y de paso utiliza Streams para calcular los totales.
Se elige este patrón debido a que el problema requiere intercambiar la lógica de conversión sin alterar el sistema. Este patrón asegura un diseño altamente flexible donde se pueden definir diferentes formas de conversión.
El usuario ingresa el número de transacciones a realizar, selecciona la moneda de origen, el monto y las monedas destino. El sistema utiliza el CurrencyExchanger con la estrategia RealExchangeStrategy para realizar las conversiones. Cada transacción queda registrada en un objeto ExchangeTransaction que almacena los resultados de conversión. Al finalizar, el sistema muestra los detalles de cada transacción y luego genera un resumen de los totales por cada moneda usando Streams. Esto permite al usuario ver tanto los valores originales como los convertidos con precisión y claridad.
Evidencia Codigo y requisitos
Evidencia Solución
Este reto sigue el patrón Decorator, de la categoría estructural, el cual permite agregar responsabilidades adicionales a los objetos (toppings al café) sin cambiar la clase base. EN este reto las principales clases son:
- Cafe es la clase abstracta que define la estructura básica de un café.
- CafeBase representa ese café básico, con descripción y precio inicial.
- ToppingDecorator es una clase abstracta que extiende Cafe y encapsula un objeto Cafe, permitiendole añadir nuevas funcionalidades.
- Subclases concretas (los toppings) es la razón del porqué de este patrón, añadiendo su propia descripción y costo extra.
- ToppingPersonalizado permite extender el sistema con toppings definidos por el usuario en tiempo de ejecución.
- La clase CafePersonalizado contiene la interacción con el usuario y el cálculo final.
Se elige este patrón porque se necesita agregar funcionalidades nuevas al objeto base sin modificar la clase original, permitiendo una composición flexible, donde los decoradores pueden combinarse en cualquier orden para formar un café totalmente personalizado.
El flujo de la aplicación comienza con el usuario eligiendo cuántos cafés quiere personalizar. Luego, para cada café, se parte de un CafeBase al que se le van agregando toppings seleccionados por el usuario mediante decoradores. Cada topping envuelve al café anterior, acumulando tanto la descripción como el precio. Finalmente, el sistema muestra un resumen detallado de cada café con su lista de ingredientes y precio total, y calcula el costo general de todos los cafés utilizando Streams.
Evidencia Codigo Implementado -Solo se agregó el codigo del Main del reto, para no congestionar de imagenes el README.
Evidencia Solución
El patron de diseño utilizado fué el de Cadena de Responsabilidad, este patron de diseño pertenece al grupo de patrones comportamentales. Se destaca por que permite que múltiples objetos tengan la oportunidad de procesar una solicitud, pasándola a lo largo de una cadena hasta que alguien la maneje.
Se escogió este patron de diseño, ya que calzaba perfectamente con el desarrollo del problema, donde los tickets empezaban desde el tecnico basico, siendo que si este podia resolver el ticket ahi acababa este, pero en el caso que no el ticket pasaba al siguiente nivel jerarquico(Con mas funcionalidades que el tecnico anterior) y se repetia esto mismo, si el nuevo tecnico no podia resolver el problema, entonces se lo delegaba al tecnico que se especializa un poco mas. A menos que ningun tecnico lo pueda desarrollar por diversos motivos, el ticket cambia de estado.
Se creó una clase abstracta tecnico, donde cada uno sabia quien era el siguiente, como era una clase abstracta, se crearon sus clases hijas siendo cada tecnico expecificamente con sus metodos sobreescritos, permitiendo que cada uno pudiera tener su logica propia para resolver un ticket o no.
Evidencia Codigo Implementado -Solo se agregó el codigo del Main del reto, para no congestionar de imagenes el README.
Evidencia Solución
En el Reto 7 se implementó el patrón de diseño Command, que pertenece a los patrones de comportamiento. Este patrón encapsula una petición como un objeto, permitiendo parametrizar clientes con diferentes solicitudes, encolar o registrar solicitudes, y soportar operaciones de deshacer.
El diseño se basa en una interfaz Command que define los métodos execute(), undo() y getDescription(). Cada acción posible del control mágico (encender luz, abrir puerta, reproducir música, ajustar volumen) se implementa como una clase concreta que implementa la interfaz Command. Así, cada comando sabe cómo ejecutar y deshacer su propia acción.
El RemoteControl actúa como invocador, recibiendo comandos y ejecutándolos, además de mantener un historial para soportar la funcionalidad de deshacer. El historial permite saber qué usuario realizó cada acción y si fue revertida.
El patrón Command fue elegido porque permite desacoplar el objeto que invoca la acción (el control remoto) del que la ejecuta (la luz, la puerta, la música, etc). Esto facilita agregar nuevas acciones sin modificar el código del invocador y permite implementar funcionalidades como deshacer, rehacer y registro de acciones de manera sencilla y extensible.
Además, el patrón Command es ideal para escenarios donde se requiere mantener un historial de operaciones, como en este reto, donde es importante saber quién realizó cada acción y si fue revertida.
Se creó una interfaz Command y varias clases concretas para cada acción (TurnOnLightCommand, OpenDoorCommand, PlayMusicCommand, AdjustVolumeCommand). Cada comando implementa la lógica de ejecución y deshacer.
El RemoteControl recibe los comandos y los ejecuta, almacenando cada acción en un historial junto con el usuario que la realizó y si fue deshecha. Esto permite mostrar un resumen detallado de las acciones y quién alteró la configuración.
El diseño facilita la extensión: para agregar una nueva acción, solo se debe crear una nueva clase que implemente Command y agregarla al control remoto, sin modificar el resto del sistema.
Evidencia Codigo y requisitos
Ver éstas imagenes primero, pues son el flujo que se sigue para la demostración de la solución.
Evidencia Solución Realizamos un caso de prueba, para lograr mostrar todas las interacciones y acciones logrables en el codigo, pues son varias y de este modo logramos que no se omita ninguna funcionalidad en la demostración.
Procuramos darle a cada clase una razón de ser, encargarse de tareas lo más especificas posibles, el animal se encarga de sus estados/comportamiento, cuidador de cuidado de animales/propinas/animales asignados, visitante fotos/propinas/favoritos, el habitat de su limpiesa, Photoservice de la persistencia, se permiten atributos dinamicos usando un map con los atributos, asi aseguramos que siga funcionando y sea extendible sin modificar nada del codigo.
Usar los principios SOLID como arquitectura del reto permite que el codigo sea mantenible, extensible y cómodamente testeable, permite una gran cohesion y simplifica entender el codigo, esto es ideal para un proyecto relativamente grande y con alta extensibilidad como lo es un zoológico con muchas funciones e información.
Nos efocamos en las clases animal, visitante, photo, cuidador, apoyadas por otras para complementar su funcionamiento manteniendo SOLID, implementamos los comportamiento directamente en las interacciones, validamos las assignaciones y especialidades de los cuidadores, mantenemos seguimiento de propinas y fotos, generamos una demo, que simplifica el demostrar el funcionamiento del codigo, pues es bastante amplio y no tiene un horizonte claro, simplente es libremente interactivo, es por eso que optamos con mostrar todas las funcionalidades del codigo con un ejemplo de uso de los metodos de las principales clases del proyecto.