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

Dúvida sobre a solução do desafio

Tenho uma dúvida sobre a minha solução para o desafio, e gostaria de saber se isso que fiz é considerado algo errado em um cenário real.

Percebi que no Controller do Abrigo estava sendo cadastrado e listado os pets relacionados a ele.

Achei que fazia mais sentido essas funcionalidades serem migradas para o controller do Pet.

Eu entendo que em um cenário real, onde o sistema já esteja em produção, essa deveria ser uma solução discutida pois exigiria uma mudança nas requisições de frontend, mas levando em consideração apenas a implementação do backend, seria uma boa prática fazer essa migração?

Minha maior dúvida está no fato de eu ter percebido que a classe Abrigo possuia um cascade ALL, então ela realmente pode manipular os Pets, por outro lado, considerei o principio da responsabilidade única do SOLID, e considerei que o controle de Abrigo deveria cuidar apenas do Abrigo, e não retornar dados de Pets.

Foi um pensamento errado ou uma boa prática a alteração que fiz? Minha compreensão do principio da responsabilidade única está correto?

No mais, agradeço desde já pelo ótimo curso.

Segue o link para a minha implementação: repositório github

2 respostas
solução!

Olá, Francisco! Como vai?

Em relação à sua dúvida, a resposta é: depende. O princípio da responsabilidade única do SOLID, como você mencionou, sugere que uma classe deve ter apenas uma responsabilidade. No entanto, em um cenário real, a decisão de migrar a funcionalidade de cadastro e listagem de pets para o controller do Pet pode depender de vários fatores.

Por exemplo, se o Abrigo é o responsável por gerenciar os Pets, pode fazer sentido que o Abrigo tenha a responsabilidade de cadastrar e listar os Pets. Por outro lado, se os Pets têm uma existência mais independente e podem ser gerenciados fora do contexto de um Abrigo, então faria sentido mover essas funcionalidades para o PetController.

Em relação ao cascade ALL na classe Abrigo, isso significa que qualquer operação feita no Abrigo será propagada para os Pets associados. Isso pode ser útil em alguns casos, mas também pode levar a efeitos colaterais indesejados se não for usado com cuidado.

Em relação ao seu entendimento do princípio da responsabilidade única, parece que você está no caminho certo! Lembre-se, o objetivo é que cada classe ou módulo tenha uma única responsabilidade. Isso não apenas torna o código mais fácil de entender e manter, mas também facilita a reutilização e a testabilidade do código.

Espero ter ajudado e bons estudos!

Opa Rodrigo,

Acho que eu já tenho uma tendência em colocar cada entidade sendo gerenciada por si só, pois em muitos casos, no evoluir das demandas, uma entidade dessa pode "crescer" e talvez a migração no futuro seja mais trabalhosa do que iniciar já com cada entidade tendo suas respectivas responsabilidades isoladas.

Muito obrigado pela resposta!