SOLID – Single Responsibility Principle (SRP)

O Single Responsibility Principle (SRP) ou Princípio da Responsabilidade Única é o primeiro e um dos mais importantes princípios da orientação a objetos (OOP).

O princípio tem como objetivo atingir as classes e suas responsabilidades dentro do sistema, é um dos mais fáceis de se entender e aplicar e tem como premissa a seguinte afirmativa:

"A class should have one, and only one, reason to change"

“Uma classe deve ter um, e apenas um, motivo para ser modificada”

Se uma classe só deve ter um motivo para ser modificada, certamente ela só deve ter uma única responsabilidade, logo:

Cada responsabilidade deve ser uma classe, porque uma responsabilidade é um eixo de mudança.

Veja esta classe:

Aqui temos uma classe, que tem uma série de responsabilidades estas que não são inerentes a ela:

• Validar Cliente;
• Calcular Imposto;
• Salvar (Persistir, seja banco ou API);
• Imprimir;
• Enviar por e-mail;

Se ela tem cinco responsabilidades ela tem cinco motivos para ser modificada. Essa quebra de responsabilidades pode gerar uma série de dores de cabeça.

Vamos supor que o método EnviarPorEmail() necessitasse ser alterado e um bug não identificado tenha sido publicado em produção.

Teríamos um cenário drástico, pois toda a estrutura da classe, e do processo, foi comprometida, o sistema deixaria de emitir notas fiscais por conta de um bug no envio de e-mail.

Além de gerar problemas graves, este tipo de acoplamento traz complexidade ao desenvolver testes além de deixa-los menos eficazes. Quando se trabalha com o tipo de arquitetura acima, tem-se a falsa impressão de que o sistema está sendo construído de forma prática e simples, pois se tem poucas classes para se dar manutenção, mas, quando elas começam a se expandir, e o sistema começa a ganhar tempo de vida, é que vemos como o sistema ficou muito mais complexo e de difícil de dar manutenção.

Quando trabalhamos com SRP podemos ter o sentimento de estarmos criando muitas classes para pouco uso, mas quando as funcionalidades do sistema crescem, podemos perceber que a expansão nada mais é do que criar novas classes nos lugares corretos e conecta-las de forma coesa. Sempre crie um sistema pensando que ele pode crescer em um momento.

Aplicando o SRP:

Quais ganhos tivemos aplicando SRP na classe?

• Facilidade de manutenção e evolução do código;
• Código limpo e de fácil entendimento;
• Facilidade para desenvolvimento de testes;
• Redução do acoplamento;
• Complexidade reduzida;
• Coesão das classes;

A quantidade de benefícios que tivemos com um simples refatoração é enorme, não temos como negar a necessidade de aplicarmos o SRP em nossas aplicações. Como disse as aplicações crescem "tem vida própria", com o tempo quando tiver que voltar a dar manutenção e ver esse desacoplamento vai se agradecer :)

Mantenha esse princípio sempre fresco na memoria, se tiver que escolher apenas um escolha o SRP.

Nos próximos artigos falarei um pouco mais sobre outros princípios do SOLID.

Referências:

• The Single Responsibility Principle
• Princípios, Padrões e Práticas Ágeis em C#