Mejoras en entidades - K3001 - Dieguez Miranda

[mirandadieguez]

2) Análisis de la capa de entidades de dominio:

• La lógica de alerta estaba acoplada a condiciones particulares en una constante dentro en el AlertasService.
• No existía una clase abstracta o interfaz para modelar condiciones genéricas.
• El dominio no soportaba nuevos tipos de condiciones.
• No se respetaban algunos principios SOLID ni buenas prácticas de diseño orientado a objetos.

3 y 5) Rediseño de la capa de dominio y documentar los cambios y justificar las decisiones de diseño:

• Antes AlertasService tenia toda la lógica de alerta. Ahora agregué la clase de dominio Alerta para encapsular una Condicion y evaluar si se cumple con un Clima.
• Antes no había polimorfismo para condiciones, pero ahora implementé una interfaz Condicion -> Esto abstrae el concepto de condición y permite extender el modelo con nuevas condiciones fácilmente.
• Agregué la clase CondicionTemperatura y CondicionHumedad, que implementan la interfaz Condicion y usan Operacion (MAYOR, MENOR, IGUAL).
• Antes la lógica de comparación estaba hardcodeada. Ahora es parametrizable mediante objetos Condicion y Operacion

Principios SOLID:

• S => Cada clase tiene una única responsabilidad: CondicionTemperatura y CondicionHumedad comparan, Alerta evalúa, AlertasService coordina.
• O => Podés agregar nuevas condiciones sin modificar el código existente.
• L => CondicionTemperatura o CondicionHumedad pueden ser reemplazadas por cualquier otra implementación de Condicion sin romper la lógica.

Atributos de Calidad:

• Claridad / Extensibilidad => Ahora es más fácil entender y extender el sistema agregando nuevas condiciones.
• Mantenibilidad => Los cambios en lógica de alerta no requieren modificar el AlertasService.