1
resposta

[Dúvida] Aplicando o S do SOLID

Do ponto de vista do S do SOLID - Single Responsiblity Principle, não seria melhor criar um service para cada endpoint do controller?

Por exemplo, um service para cada item do CRUD.

1 resposta

Olá, Rodrigo! Tudo bem?

Compreendo sua dúvida e acho que ela é muito relevante! O princípio da Responsabilidade Única (Single Responsibility Principle - SRP) do SOLID é uma diretriz importante para manter nosso código organizado e manutenível.

No entanto, a aplicação do SRP não significa necessariamente que devemos ter um serviço para cada endpoint do controller. Na verdade, o SRP sugere que uma classe deve ter apenas um motivo para mudar, ou seja, deve ter apenas uma responsabilidade.

No contexto da nossa API Java, um serviço geralmente é responsável por um domínio específico do nosso aplicativo. No exemplo da aula, temos o PetService e o AbrigoService. O PetService é responsável por todas as operações relacionadas a pets, enquanto o AbrigoService é responsável por todas as operações relacionadas a abrigos.

Se seguíssemos a ideia de ter um serviço para cada endpoint, poderíamos acabar com uma quantidade excessiva de classes, o que pode tornar o código mais difícil de gerenciar e entender. Além disso, poderíamos ter muita duplicação de código, já que vários endpoints podem compartilhar a mesma lógica.

Por exemplo, se tivéssemos um PetCreateService, PetReadService, PetUpdateService e PetDeleteService, todos esses serviços provavelmente precisariam interagir com o PetRepository. Isso significaria que teríamos que injetar o PetRepository em todos esses serviços, o que é uma duplicação desnecessária.

Em vez disso, podemos ter um único PetService que encapsula toda a lógica relacionada a pets. Esse serviço pode ter métodos como createPet, getPet, updatePet e deletePet, cada um correspondendo a um endpoint específico do PetController. Dessa forma, mantemos nosso código DRY (Don't Repeat Yourself), fácil de entender e manter.

Espero ter ajudado e bons estudos!