Mejoras en entidades - Curso K3101 - Vultaggio, Pablo Nicolás

[nicolasvultaggio]

Cambios:
-Generacion de DTO input y output EMAIL
Cohesión: No le corresponde al controller de emails conocer entidades de dominio y utilizar sus metodos
Principio de inversion de dependencias: Los modulos de alto nivel no deben depender de modulos de bajo nivel, si no abstracciones.
-Abstraccion de Adapter para enviar email
Email ya no tiene un metodo enviar(), si no que, el EmaiService conoce un IEmailSender que se encarga de el enviado de emails, como este quiera hacerlo.
Single Responsibility: La unica responsabilidad del adaptador es traducir lo que que quiere enviar el service a la forma real de envio.
Open Closed: Podemos agregar nuevas maneras de enviar emails facilmente
Menos acoplamiento a una logica determinada para enviar un email
Cohesion: Los emails no se encargan de enviarse a si mismos, si no, una clase determinada que solo se encarga de enviar emails
Flexible ante cualquier cambio de forma para enviar emails
Liskov substitution principle: no conocemos al adaptador directamente, si no una interfaz que este adaptador implementa
-Abstraccion de detector de alertas:
El AlertaService conoce un IAlertDetecter que abstrae la logica interna para detectar alertas
Open Closed Principle: si qeuremos generar otro detector, simplemente creamos otra clase, no modificamos la anterior
Cohesion: AlertaService no se encarga de detectar Alertas, si no que hay toda una clase especifica para esa funcionalidad
Flexible ante cualquier cambio de logica para detectar alertas en el futuro
Liskov substitution principle: no se conoce al detector directamente, si no con una interfaz que implementa
-Generación de la clase Ciudad / Region / Pais
El Clima conoce una Ciudad
La Ciudad conoce un su nombre (string) y su Region
La Region conoce su nombre y su PaísEl País conoce su nombre
Cohesión y Single Responsibility Principle: antes clima gestionaba que Ciudad, region y pais tengan sentido, ahora simplemente conoce su ciudad, la ciudad conoce la region y la region conoce el pais, todas tienen una responsabilidad sola.
Open Closed Principle:Si quisieramos agregar mas clases de locaciones dentro de la ciudad, no hace falta modificar el clima.
Clima esta menos acoplado a los 3 datos por separado, si no que solo conoce a la ciudad
Cada clase (Ciudad, Region, Pais) encapsula sus propios datos y puede implementar lógica específica, esto es extensible
Podemos usar Ciudad Region y Pais en futuras partes del sistema
Mantenibilidad / modularidad el hecho de que podamos modificar un pais sin tocar siquiera la clase clima
-Generacion de la clase Temperatura:
El Clima conoce su Temperatura
Temperatura conoce la temperaturaCelsius como atributo y puede tambien responder la temperaturaFarenheite ya que es un metodo interno que hace la conversion.
O sea, responde tanto al metodo getTemperaturaCelsius (un getter) y getTemperaturaFarenheite()
Singre Responsibility Principle: ahora la clase clima pierde la responsabilidad de coordinar ambas temperaturas, si no que solo la guarda en celsius y el encargado de transformarlo a Farenheit es la clase Temperatura
Open Closed Principle: si queremos agregar otro tipo de temperatura, no debemos generar mas atributos y mas metodos de conversion, lo que tardaria mucho, si no que se lo delegamos todo a la clase Temperatura, que conoce primero todo en celsius
Cohesión: le quitamos la responsabilidad de la conversión a Clima y se la damos a Temperatura
Flexible : es facil agregar otro tipo de temperatura, esto es mantenible
La clase Temperatura es rehusable en posibles nuevas implementaciones

-Generacion de clase Alerta con la informacion necesaria del clima para generacion de emails
Ahora cuando detectamos una alerta, no generamos un mail con los datos del clima, si no que instanciamos una Alerta con los datos del clima relevantes para informar y lo guardamos en un repositorio de Alertas.
Single Responsibility Principle: Los emails ya no son los encargados de representar implicitamente a las alertas, por eso estas tienen su propia entidad: esto es cohesivo
Open Closed Principle: Es facil ahora poder modificar a las alertas, ya sea:
Agregando tipos de alertas.
Podemos agregarle metodos y funcionalidades a las alertas en el futuro sin tocar la logica de los emails.
Estos cambios son mantenibles, flexibles y cohesivo, mantienen bajo acoplamiento entre los climas / emails y alertas.

Otros cambios que no tienen nada que ver con las entidades de dominio, pero me pareció bien implementarlos
-Sobre el guardado de climas
Obtenemos de un repositorio, todas las ciudades guardadas en el sistema
Las ciudades conocen sus climas, no viceversa.
Como los climas pertenencen a las ciudades, por eso
al momento de actualizar los climas, pedimos un clima de una ciudad especifica
y lo guardamos en la lista de climas de la ciudad
-Para chequear alertas, vemos, para todas las ciudades, el ultimo clima traido al sistema
si no fue procesado y cumple condicion de alerta, se genera una Alerta y se guarda en el repositorio de alertas
-Luego, cada 1 minuto, se revisan las alertas no procesadas, por cada una se genera un mail y se guarda
-Cada 1 minuto se procesan mails pendientes y se envian

-No se usa mas repositorio de climas ¿Por que?
Los climas pertenecen SOLO a las ciudades, por lo tanto, no hace falta guardarlas en un repositorio
ya que alcanza guardandolas dentro de una ciudad que lugo se almacena persistentemente en el repositorio de ciudades