Quase todo mundo sabe o que é, mas poucos o definem. Sigo a definição original do Uncle Bob, já que este é um dos seus princípios SOLID. Segundo Mr. Robert C. Martin, o princípio da responsabilidade única define que “nunca deve haver mais de um motivo para uma classe mudar”, ou ainda, “uma classe só deve mudar por um único motivo”. Mais conhecido como Single Responsibility Principle (SRP).

Pronto, pare de se preocupar se o método/propriedade/evento que você está introduzindo faz parte do objeto ou não. Faça-se esta pergunta: esta classe vai ter que mudar por mais um motivo com esta introdução que estou fazendo? Se sim, o método/propriedade/evento está na classe errada.

O mesmo vale para métodos. Eles devem ter apenas um motivo para mudar.

Assim, se você fez uma classe “produto”, e ela abstrai um produto da empresa, então ela só deve mudar se uma das características abstraídas do produto da empresa mudarem. Se, por acaso, a classe de produto mandar e-mail quando um preço subir, essa é uma razão a mais para ela mudar: o método de envio de e-mails pode mudar. Ou se a classe de produtos passar a controlar o estoque: esse é outro motivo para mudar, talvez a maneira de manter o estoque mude.

Qual o resultado disso? Muitos métodos pequenos, com muitas classes pequenas. Muita modularidade. Excelente!

– Mas em OO não devemos colocar dados e comportamento juntos?

Claro! Mas o que isso tem a ver com a história? Eles continuam juntos, mas modularizados. Agora, só porque você criou uma classe de produto, a tal classe tem que ir no banco, se configurar, obter dados, dar desconto, assobiar e chupar cana?

– Mas eu vou ficar com muitas funções pequenas na minha classe. Não vou conseguir entender.

Você já fica com poucas funções gigantes, que são ainda mais difíceis de entender. Depois do quinto nível de identação, ninguém mais sabe se aquele “}” está fechando um “if”, um “while”, um “for”, ou o que for. Ainda por cima, funções gigantes tem um problema sério de efeitos colaterais, mas isso é outro problema. Com muitas funções, cada uma vai fazer só uma coisa, e vai fazer ela direito. É o paraíso do teste unitário!

– Mas eu vou ficar com muitas classes no sistema. Não vou conseguir entender.

Vai conseguir entender sim. Você dá nomes corretos para cada uma. Em vez de criar um “cliente”, e lá dentro colocar um código para “AvaliarSePodePromoverParaPremium”, você cria a classe cliente, e uma classe de serviço “AvaliadorDeClientePremium”, com o tal método “AvaliarSePodePromoverParaPremium”. Pronto, duas classes colaborando. Tudo mais modular, o cliente ficou mais fácil de entender, e a tal função “AvaliarSePodePromoverParaPremium” ficou mais fácil de testar (se você estiver trabalhando com abstrações).

Lembre-se desse princípio. É um dos mais importantes que você vai encontrar.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.