Mejoras en entidades - K3001 - Vecchio Kiara

[KiaraDVecchio]

Mejoras propuestas

1. Modelado de la entidad Ciudad:
   Cree una clase Ciudad que encapsula nombre, región y país
   Ahora Clima contiene un objeto Ciudad en lugar de un String para mayor claridad y extensibilidad.
   Justificación

   • Principio SRP: Ciudad encapsula la lógica y los datos geográficos, separando esta responsabilidad de la clase Clima, que se enfoca más en lo meteorológico.
   • Mejora la cohesión: los atributos relacionados se agrupan en una entidad clara y específica.
   • Aumenta la reusabilidad y la comprensibilidad del código.

2. Creación de CondicionAlerta:
   La evaluación de alertas se implementó en una nueva clase para encapsular los valores de alerta de la humedad y temperatura.
   Se eliminó el método cumpleCondicionesAlerta() de AlertasService.
   Justificación:

   • Principio SRP: CondicionAlerta se encarga de una única cosa, decidir si hay condiciones extremas.
   • OCP: permite agregar más reglas sin modificar AlertasService, simplemente cambiando la implementación de CondicionAlerta.
   • Mejora la mantenibilidad, permitiendo cambiar la lógica de decisión sin tocar otras clases.

3. Creación de la clase Alerta:
   Esta clase se usa en una situación climática extrema que requiere notificación.
   Se encarga de generar un mensaje de alerta y construir un Email.
   Justificación:

   • Principio SRP: se separa la representación del evento meteorológico (Clima) de la acción de notificación (Email).
   • Mejora el bajo acoplamiento: evita que AlertasService sepa cómo se construye el mensaje.

4. Actualización de ClimaService:
   Se adaptó para trabajar con múltiples ciudades obtenidas desde application.properties (ciudades.argentina).
   Se modificó la lógica para instanciar correctamente Ciudad a partir del WeatherResponse.
   Justificación:

   • OCP: se puede modificar las ciudades sin cambiar código.
   • Elimina valores hardcodeados, lo que mejora la mantenibilidad.

5. Modificación del AlertasService:
   Se delegó la lógica a CondicionAlerta y Alerta.
   Justificación:

   • Principio SRP: AlertasService ahora solo coordina y no contiene lógica de negocio.
   • Aumenta la modularidad y la extensibilidad, favoreciendo cambios futuros sin romper la estructura existente

6. Refactor de Email.java:
   Apliqué el patrón Adapter mediante la interfaz IEmailAdapter.
   Se agregó un método configurarAdapter(...) y se desacopló el método enviar().
   Justificación:

   • Bajo acoplamiento y alta cohesión, ya que Email solo sabe delegar el envío.
   • Mejora la testabilidad al poder mockear el adapter sin enviar correos reales.

7. Creación de DTOs para Email:
   Agregué los DTOs EmailInputDTO y EmailOutputDTO .
   Justificación:

   • Mejora la seguridad y robustez, evitando que el cliente altere campos como el remitente.