[S.O.L.I.D.] Os Cinco Pilares da Programação Orientada a Objetos. [S] - Single Responsibility Principle - SRP

Olá devs, venho trazer uma série de 5 artigos abordando com teoria e exemplos de código em java, cada letra que simboliza os princípios da palavra SOLID, caso você não saiba, SOLID é um acrônimo para cinco princípios fundamentais do design orientado a objetos (POO), estabelecidos por Robert C. Martin ("Uncle Bob"). Esses princípios visam aprimorar a qualidade, a manutenibilidade e a extensibilidade do código, tornando-o mais robusto e resiliente às mudanças.

Neste artigo comecarei falando sobre o primeiro princípio que é:

[S] - Single Responsibility Principle,
Princípio da Responsabilidade Única - SRP
“Nunca deve haver mais de um motivo para uma classe mudar.”

Afirma que cada módulo de software (classe, método, etc.) deve ter apenas uma única responsabilidade. Em outras palavras, cada módulo deve ser responsável por uma única função bem definida e não deve se preocupar com nenhuma outra função.

Vantagens do SRP:

1. Maior modularidade: O SRP leva a um código mais modular, o que facilita o entendimento, a manutenção e a reutilização. Módulos menores e mais focados são mais fáceis de compreender e modificar, sem afetar outras partes do código.
2. Maior coesão: O SRP promove maior coesão dentro dos módulos, garantindo que cada módulo se concentre em uma única tarefa e que todo o código dentro do módulo esteja relacionado a essa tarefa. Isso resulta em um código mais organizado e menos propenso a erros.
3. Maior flexibilidade: O SRP torna o código mais flexível e adaptável a mudanças. Se a necessidade de modificar o código surgir, é mais provável que apenas um módulo precise ser alterado, minimizando o impacto em outras partes do sistema.
4. Maior testabilidade: O SRP facilita a testabilidade do código, pois cada módulo pode ser testado de forma independente, isolando-o de outras dependências. Isso garante que cada módulo funcione conforme o esperado e facilita a identificação de erros.
5. Maior reutilização: O SRP promove maior reutilização de código, pois módulos com única responsabilidade são mais fáceis de serem entendidos e integrados em outros projetos.

Dividir uma classe grande em classes menores: Se uma classe possui várias responsabilidades distintas, ela pode ser dividida em classes menores, cada uma com uma única responsabilidade.
Criar interfaces para abstrair responsabilidades: Interfaces podem ser usadas para abstrair responsabilidades de classes concretas, permitindo que diferentes classes implementem a mesma interface de maneiras diferentes.

Vamos a um exemplo com e sem SRP.

Classe EmployeeService sem SRP

Nesta implementação, a classe EmployeeService lida com:

• Operações CRUD para Employee.
• Envio de notificações por email.
• Gerenciamento de endereços.
• Isso torna a classe difícil de manter e estender, pois mudanças em uma responsabilidade podem afetar outras.

Com SRP
Aplicando o SRP, separamos as responsabilidades em diferentes classes, cada uma com uma única responsabilidade. Isso torna o código mais modular e fácil de manter.

Classe EmployeeService com SRP

Classe EmployeeService

Classe NotificationService

Classe AddressService

Classe EmployeeRepository

Classe AddressRepository

Ao aplicar o SRP, separamos claramente as responsabilidades, facilitando a manutenção e a extensão do código. Agora, cada classe tem uma única responsabilidade, tornando o sistema mais modular e fácil de entender.

PS: Para ir direto para o próximo princípio: