Não faz muitos anos que me deparei com uma apresentação do Uncle Bob em que ele falava de SRP e dava uma explicação completamente diferente do que é a compreensão comum sobre o tema.
SRP não é sobre um módulo ter apenas uma responsabilidade, nem por fazer apenas uma coisa.
Isso foi assustador porque eu já havia, inclusive escrito, com base nessa ideia errada.
Primeiro vamos entender o que Uncle Bob diz sobre isso em Clean Architecture.
De todos os princípios SOLID, o Princípio da Responsabilidade Única (SRP) provavelmente é o menos compreendido. Isso se deve, possivelmente, ao seu nome bastante inadequado. Em geral, ao escutarem esse nome, os programadores imaginam logo que todos os módulos devem fazer apenas uma coisa.
Não se engane, saiba que há um princípio como esse. Uma função deve fazer uma, e apenas uma, coisa. Usamos esse princípio quando refatoramos funções grandes em funções menores; usamos isso nos níveis mais baixos. Mas ele não é um dos princípios SOLID — não é o SRP.
Historicamente, o SRP tem sido descrito como:
Um módulo deve ter uma, e apenas uma, razão para mudar.
Os sistemas de software mudam para atender às demandas de usuários e stakeholders. Esses usuários e stakeholders são a “razão para mudar” da qual o princípio fala. De fato, podemos reformular o princípio da seguinte forma:
Um módulo deve ser responsável por um, e apenas um, usuário ou stakeholder.
Infelizmente, as palavras “usuário” e “stakeholder” não são realmente as expressões corretas nesse caso. Quase sempre há mais de um usuário ou stakeholder exigindo que o sistema mude da mesma forma. Então, estamos nos referindo efetivamente a um grupo — uma ou mais pessoas que exigem essa mudança. Vamos nos referir a esse grupo como um ator.
Portanto, a versão final do SRP é:
Um módulo deve ser responsável por um, e apenas um, ator.
Então, o que significa a palavra “módulo”? Pela definição mais simples, é apenas um arquivo-fonte. Na maior parte das vezes, essa definição funciona bem. Em algumas linguagens e ambientes de desenvolvimento, no entanto, não há arquivos-fonte que contenham o código. Nesses casos, um módulo é apenas um conjunto coeso de funções e estruturas de dados. Esta palavra “coeso” sugere o SRP. Coesão é a força que amarra o código responsável a um único ator.
Talvez a melhor maneira de entender esse princípio seja observando os sintomas decorrentes da sua violação.
Sintoma 1: Duplicação Acidental
Meu exemplo favorito é a classe Employee de uma aplicação de folha de pagamento. Ela tem três métodos: calculatePay(), reportHours(), e save().
Essa classe viola o SRP porque esses três métodos são responsáveis por três atores bem diferentes.
– O método calculatePay() é especificado pelo departamento de contabilidade, subordinado ao CFO.
– O método reportHours() é especificado e usado pelo departamento de recursos humanos, subordinado ao COO.
– O método save() é especificado pelo administradores de base de dados (DBAs), subordinados ao CTO.
Ao incluírem o código-fonte desse três métodos em uma única classe Employee, os desenvolvedores acoplaram cada um desses atores aos outros. Esse acoplamento pode fazer com que as ações da equipe do CFO prejudiquem algo de que a equipe do COO dependa.
Martin, Robert C.. Arquitetura Limpa: O guia do artesão para estrutura e design de software (Robert C. Martin)
Então claramente não estamos falando de fazer apenas uma coisa, mas de ter apenas um responsável.
Essa é uma mudança conceitual drástica a respeito do que é dito, do que é interpretado e do que realmente se trata.
O que fez com que não entendêssemos?
Ao não usar nomes próprios, o nome dá o sentido, e apresenta a ideia antes de qualquer detalhamento a respeito dela.
Princípio da Responsabilidade Única: É óbvio pensar que se trata de que algo deva ter uma única responsabilidade.
Usamos o viés de confirmação e o nome para pensar nisso, sem levarmos em conta o que de fato se trata. Todos nós já vimos códigos que faziam coisas demais, é natural pensar que o princípio enderece esse problema.
Mas não é sobre isso.
Conclusão
Então, chegamos ao final dessa jornada sobre o verdadeiro significado do Princípio da Responsabilidade Única (SRP) dentro dos princípios SOLID. Se você chegou até aqui, já percebeu que SRP não é sobre “fazer uma coisa só”. É sobre ter clareza de quem ou o que está ditando as mudanças no seu código.
Essa distinção pode parecer sutil, mas é fundamental. Entender que um módulo deve ser responsável por um único ator ou grupo de interesses específicos é o que realmente faz a diferença na hora de manter seu código limpo, organizado e fácil de manter.
Então, da próxima vez que você estiver projetando ou refatorando uma aplicação, lembre-se: o SRP não se trata de “não fazer muito“, mas sim de “não misturar responsabilidades“. E isso, no longo prazo, é o que vai manter seu código à prova de balas.
Agora, é hora de colocar isso em prática e ver a mágica acontecer!
Bem esclarecedor. Eu, colegas e ex-colegas sempre tínhamos aquela visão de “fazer apenas uma coisa” por classe.
E faz muito mais sentido o conteúdo do artigo do que o que praticamente todo mundo pensa