Mejoras en entidades - K3001 - Sagrada Tomas #14
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cambios
-Implementacion de un input de emails porque esto flexibiliza mas el ingreso de los datos, y cumple el principio OCP, ya que permite agregar cambios sin tener que modificar todo el codigo del service.
-Cambio de los atributos de TEMPERATURA_ALERTA y HUMEDAD_ALERTA, de AlertasService, para que no esten hardcodeados, porque esto hace que el codigo quede mas limpio y ademas mas modificable, ademas le quita responsabilidades al AlertasService. Para esto se creo un alertasConfig de donde se van a sacar los valores de alerta.
-Uso del application.properties para desharcodear los valores del emailScheduler y tambien de la cantidad de hilos, esto igual que el anterior lo hace ams facil de modificar y ademas permite el cambios sin tener que hacer cambios en emailScheduler.
-Cambio de todos los atributos en clima que tenian que ver con una ubicacion por una nueva clase Ubicacion. Esto mejora mas la organizacion del codigo y le saca responsabilidad al clima, permite futuras responsabilidades a ubicacion.
-Cambio de las temperaturas a una clase, donde solo se guarda un tipo el otro se puede calcular si es necesario, esto le da mas consistencia a los datos.
-Se utilizo el patron adapter para el envio de mails (mockeado no se envian realmente), ademas se agrego manejo de errores en este proceso. El uso de adapters permite el patron de responsabilidad simple, porque el adapter va a tomar responsabilidad del envio del mail. Ademas se cumple el OCP (ya que el adapter esta abierto a extenderse pero no a modificaciones) y se utiliza una inferfaz simple y especifica. Si falla el envio del email se borra (ya que no se tiene especificacion para esos pasos, y si se guarda simplemente con el enviado en false, va a entrar en un bucle de intentar enviarlo constantemente)
-Se cambio la responsabilidad del enviar al service del email, ya que tiene mas sentido que el service se encargue del flujo del envio mas que la entidad.