El método login cambia de comportamiento según sea el rol, lo que contradice el diseño LSP, ya que necesita un role como parámetro para que la implementación funcione. Lo que quiere decir que no podremos inyectar un UserService y asumir que se comporte igual a cualquier role.
Como solucion:
Quitamos el parámetro UserRole ya que cada clase presentará un rol específico.
Dividimos la clase UserServiceImpl en dos clases específicas CustomerUserService y SellerUserService las cuales implementan la interfaz UserService eliminando la lógica condicional (if/ equals(role)).
Como resultado, cada clase representa un comportamiento específico, además podremos agregar un nuevo tipo de usuario sin modificar el código existente lo que cumpliría OCP también.
El método login cambia de comportamiento según sea el rol, lo que contradice el diseño LSP, ya que necesita un role como parámetro para que la implementación funcione. Lo que quiere decir que no podremos inyectar un UserService y asumir que se comporte igual a cualquier role.
Como solucion:
Quitamos el parámetro UserRole ya que cada clase presentará un rol específico.
Dividimos la clase UserServiceImpl en dos clases específicas CustomerUserService y SellerUserService las cuales implementan la interfaz UserService eliminando la lógica condicional (if/ equals(role)).
Como resultado, cada clase representa un comportamiento específico, además podremos agregar un nuevo tipo de usuario sin modificar el código existente lo que cumpliría OCP también.