SOLID — Single Responsibility Principle (SRP)
Introduzidos por Robert C. Martin, também conhecido como “Uncle Bob”, famoso pela autoria dos livros “Clean Code”, “Clean Coder” e “Clean Archicteture”, os princípios SOLID estão diretamente ligados a programação Orientada a Objetos, com o intuito de ajudar o programador a escrever códigos mais limpos, separando responsabilidades, diminuindo acoplamentos, facilitando a refatoração e estimulando o reaproveitamento do código.
O termo SOLID é um acrônimo dos princípios: Single Responsibility (Responsabilidade Única); Open Closed (Aberto Fechado); Liskov Substitution (Substituição de Liskov); Interface Segregation (Segregação de Interfaces); e Dependence Inversion (Inversão de Dependências). Embora os conceitos tenham sido introduzidos em seu artigo “Design Principles and Design Patterns” em 2000, o acrônimo em si foi sugerido por Michael Feathers algum tempo depois.
SRP — Single Responsibility Principle
O Single Responsibility Principle ou Princípio da Responsabilidade Única, define que uma classe deve ter um, e somente um, motivo para mudar. Ela deve ser especializada em um único assunto e possuir apenas uma única responsabilidade dentro do seu software.
Acaba sendo comum na programação orientada a objetos, a criação de classes que fazem de tudo, também chamadas de God Class ou Classe Deus, onde em um primeiro momento isso pode parecer inofensivo, mas como as responsabilidades acabam se misturando, quando há a necessidade de realizar alterações nessa classe, fica difícil modificar uma dessas responsabilidades sem comprometer as outras. Toda alteração acaba sendo aplicada com um certo nível de incerteza, tornando-se um pesadelo para o programador (principalmente quando não se faz uso de testes automatizados).
Problemas
Ao violar o princípio de responsabilidade única, podemos gerar alguns problemas para o nosso software, como por exemplo:
- Dificuldades para reaproveitar o código;
- Alto acoplamento: quanto mais responsabilidades, maior o número de dependências, que por sua vez, deixa o sistema engessado;
- Dificuldades na implementação de testes automatizados: fica cada vez mais difícil “mockar” esse tipo de classe;
- Falta de coesão: a classe acaba assumindo responsabilidades que não são suas;
Exemplo prático
A classe abaixo, apresenta uma violação do princípio de responsabilidade única. Veja se você consegue identificar esta violação com base no que aprendemos até agora:
A classe TLogger viola o SRP porque realiza 2 tipos distintos de tarefas. Além de gerar o log propriamente dito, ela também é responsável por enviar um e-mail de notificação. Lembre-se, o princípio da responsabilidade única preza que uma classe deve ter um, e somente um, motivo para mudar.
Aplicando o SRP na classe acima, podemos refatorar o nosso código criando duas classes, cada uma com sua finalidade específica, da seguinte forma:
Nota: O princípio da responsabilidade única não se limita somente a classes, ele também pode ser aplicado em métodos e funções.
Conclusão
Na minha opinião, o SRP é um dos princípios mais importantes do SOLID. Ele acaba sendo a base para os demais princípios e padrões de projetos, porque aborda assuntos como acoplamento e coesão, características essenciais que todos os códigos orientado a objetos deveria ter. Aplicando este princípio, automaticamente você estará escrevendo um código mais limpo e de fácil manutenção!
Código fonte: GitHub
Referências: Clean Code (Uncle Bob), Design Principles and Design Patterns, Wikipedia e O que é SOLID
