Solucionado (ver solução)
Solucionado
(ver solução)
3
respostas

[Dúvida] Sobre a criação da entidade User.

Seria viável ao criar a classe médico e paciente com login e senha incorporados desde o início, encarregando-os das implementações de segurança e autenticação, ou em casos que uma única entidade de usuário, não seria mais apropriado gerar um usuário específico na aplicação, atribuir as devidas permissões e, nos controladores e serviços correspondentes, implementar a lógica de autenticação. Dessa forma, evita-se a criação de uma nova entidade exclusivamente para esse propósito ?

Nesse quesito, fiquei com esta dúvida, somente.

3 respostas

Olá, Matheus.

Tudo bem?

Entendi a sua dúvida, e é uma excelente questão. Em muitos casos, a decisão entre incorporar a autenticação diretamente nas entidades (como Médico e Paciente) ou criar uma entidade separada para usuários depende das necessidades específicas do seu aplicativo.

Se cada entidade (Médico e Paciente) tiver seu próprio conjunto de credenciais e regras de autenticação, pode fazer sentido incorporar a autenticação diretamente nessas classes. No entanto, isso pode levar a duplicação de código e tornar mais difícil a manutenção, já que você terá que gerenciar a autenticação em vários lugares.

Por outro lado, criar uma entidade separada para usuários pode simplificar o gerenciamento de autenticação, já que todas as informações de login e as regras de autenticação estarão em um único lugar. Isso pode tornar seu código mais limpo e fácil de manter. Além disso, se você decidir adicionar mais tipos de usuários no futuro, será mais fácil adicionar esses tipos de usuários sem ter que modificar suas classes Médico e Paciente.

Por exemplo, você pode ter uma classe User que contém as informações de login e as permissões do usuário. Então, você teria classes separadas para Doctor e Patient que contêm as informações específicas para esses papéis. A classe User poderia então ter uma referência para a instância apropriada de Doctor ou Patient.

Aqui está um exemplo de como isso poderia ser estruturado:

public class User {
    private String username;
    private String password;
    private String role; // pode ser "DOCTOR" ou "PATIENT"
    private Doctor doctor; // se o usuário for um médico, isso será preenchido
    private Patient patient; // se o usuário for um paciente, isso será preenchido
    // ... outros campos e métodos
}

public class Doctor {
    // ... campos e métodos específicos do médico
}

public class Patient {
    // ... campos e métodos específicos do paciente
}

No seu controlador de autenticação, você poderia então verificar o papel do usuário e chamar os métodos apropriados com base nesse papel.

Espero ter ajudado e bons estudos!

No caso, poderia aplicar a Herança, sendo cada entidade filha de User, ou aplicar a composição, respeitando o Princípio da Substituição de Liskov, passando os próprios atributos da classe User, que indicam se ele é um doctor ou patient, e criar um construtor que, em uma rota específica, aplique 'a' ou 'b' conforme necessário, sendo esta lógica aplicado definindo a rota no controller ?

solução!

Olá, novamente.

Tanto a herança quanto a composição são abordagens válidas, e a escolha entre elas depende das necessidades específicas do seu sistema.

Ao escolher entre herança e composição para lidar com a autenticação em entidades como Médico e Paciente, considere o seguinte:

Herança:

  • Use classes base (por exemplo, User) e subclasses (Doctor, Patient) para herdar atributos e comportamentos comuns.
  • Subclasses podem adicionar atributos/métodos específicos.
  • Cuidado com possíveis problemas de herança, como o problema do diamante.

Composição:

  • Utilize uma classe principal (User) com atributos comuns e referências a instâncias de Doctor ou Patient, dependendo do papel do usuário.
  • Flexibilidade é maior, pois evita problemas de herança.
  • Adapta-se bem a mudanças futuras na estrutura do usuário.

Escolher entre as duas depende da complexidade do domínio e das relações entre as entidades, com a composição muitas vezes sendo preferida pela flexibilidade e menor complexidade.