O problema desses artigos é que trazem exemplos muito simplórios, que mostram apenas essas classes vazias em vez de mostrar a funcionalidade em um projeto real. Vou tentar explicar neste comentário, mas se não for o suficiente me avisa que faço um artigo ou uma video aula sobre isso.
Se faz sentido ou não, depende do tamanho do projeto e de como o projeto está organizado.
Pode fazer sentido, sim, ter módulos e classes diferentes para funcionalidades diferentes, por mais que os dados utilizados sejam os mesmos. Além disso, pode fazer sentido até ter os dados duplicados no banco de dados, dependendo de como o projeto está organizado.
A ideia de separar as coisas em responsabilidades únicas é evitar que as solicitações de alteração e evolução de uma funcionalidade impacte diretamente outra funcionalidade.
Nesse caso temos as funcionalidades de Registro de usuário e de Login de usuário, que são funcionalidades que imaginamos que sempre andam de mãos dadas. Mas a realidade é que os requisitos de Login podem sofrer alterações que não deveriam impactar diretamente o registro de usuários e vice-versa.
Vamos pegar a classe que mantém tudo junto no mesmo arquivo e pensar na sequência de eventos:
- Chegou o requisito de que o usuário pode fazer o login com o email e com cpf : aumenta um pouco o código de login. O arquivo fica um pouco maior.
- Chegou o requisito de que o usuário pode cadastrar vários e-mails pra receber notificações : aumenta o código de registro de usuários E o código de login.
- Chegou o requisito de que também tem que ter os dados de endereço : aumenta o código de registro, mas não afeta o login.
- Chegou o requisito de que agora precisa usar 2-factor-authentication : aumenta o código de login e junto com os dados do usuário vão estar os dados do 2-factor-authentication.
- Bug: os vários e-mails eram apenas para envio de notificação, tem que ter um e-mail principal que é usado pra login : afeta o código existente de registro e de login.
Com o passar do tempo as classes vão ficando enormes e complexas, cada vez mais difícil de dar manutenção e adicionar novas funcionalidades. Isso para projetos que crescem muito e tem muita mudança de requisito
Agora pensando no código em que existe uma classe para cada funcionalidade, ainda vai existir um vínculo entre o login e o usuário, mas as regras serão totalmente separadas.
Vamos ver como fica o tratamento da mesma sequência de requisitos:
- Chegou o requisito de que o usuário pode fazer o login com o email e com cpf : aumenta apenas o código da classe de login. O de registro de usuário se mantém igual.
- Chegou o requisito de que o usuário pode cadastrar vários e-mails pra receber notificações : aumenta o código de registro de usuários E surgem as dúvidas: como o código do login é separado, qual e-mail vai ser considerado? É pra considerar todos também? Dependendo da resposta pode ter alteração ou não.
- Chegou o requisito de que também tem que ter os dados de endereço : aumenta o código de da classe de registro, mas não afeta o login.
- Chegou o requisito de que agora precisa usar 2-factor-authentication : aumenta o código de login, porém as configurações de login serão armazenadas e validadadas sem afetar o registro de usuário diretamente, podendo ser configurada em outros momentos após o registro de usuários.
A ideia é que as classes sejam pequenas, apenas com as regras que fazem sentido para determinada funcionalidade. Com isso os códigos tendem a ser mais simples, e o crescimento do projeto pode ser feito de forma modularizada e organizada.
Tenha em mente que é uma tentativa, é uma preocupação que você vai ter na hora de desenvolver. Não é garantia de que os bugs vão sumir, e nem de que outros desenvolvedores vão entender com facilidade as decisões que foram tomadas ao longo do tempo.
É necessário sempre manter essa preocupação, e sempre tomar as decisões em conjunto com o time. Desta forma todos vão estar cientes do porquê determinadas funcionalidades estão juntas e outras estão separadas.
Me diz aí se ajudei a entender o conceito, ou se te deixei mais confuso 😂