Se você está começando agora no mundo da programação, estudar os Princípios SOLID, criados por Robert C. Martin (também conhecido como Uncle Bob), pode ser como achar uma receita para escrever códigos mais claros, organizados e fáceis de dar manutenção.

O Princípio da Responsabilidade Única (do inglês Single Responsibility Principle – SRP), é o primeiro dos cinco Princípios SOLID. Apesar de ser um conceito simples, ele faz muita diferença à medida que seu código se torna mais robusto e seu programa ganha complexidade.

Neste artigo, meu objetivo é te ajudar a entender, de maneira simples, o que esse princípio quer dizer e como você poder implementar ele no seu código.

De onde surgiu esse conceito?

Apesar de Robert C. Martin ter popularizado o SRP, a ideia por trás dele é ainda mais antiga. Ela veio dos estudos de Tom DeMarco e Meilir Page-Jones, que falavam sobre algo chamado “coesão”

Na visão deles, coesão representava o nível de conexão entre as partes de um módulo, isto é, o quanto os elementos de uma classe estão relacionados entre si.

Uncle Bob então resgatou essa ideia e a adaptou para o que hoje entendemos como o Princípio da Responsabilidade Única, associando o conceito às razões que fazem o código mudar.

O que é o Princípio da Responsabilidade Única?

Como o nome já diz, essa regra fala que cada parte do código deve ter só uma responsabilidade. Na prática isso quer dizer que ao escrevermos uma classe devemos nos atentar para que ela tenha somente um objetivo, uma só missão, apenas um motivo para existir.

Por uma classe deve ter somente uma responsabilidade?

De acordo com Uncle Bob, cada responsabilidade em uma classe representa um “eixo de mudança”. Se uma classe faz muitas coisas diferentes, ela vira um código frágil e bagunçado. Qualquer mudança em uma parte pode acabar quebrando outra que não tem nada a ver com isso. Além disso, fica mais difícil testar e manter o código assim.

Principais vantagens de aplicar o SRP

• Manutenção mais tranquila: Se você mudar algo mudar em uma funcionalidade isso não quebrará outras partes do sistema;
• Facilidade na hora de criar testes: Cada classe pode ser testada de forma isolada;
• Reutilização de código: Códigos bem separados tendem a ser mais reutilizáveis, funcionando como peças de Lego;
• Código mais fácil de entender: Um código limpo é muito mais fácil de debugar, seus colegas (e seu eu do futuro) vão te agradecer;
• Melhor Escalabilidade: Adicionar novas funcionalidades ao código fica mais fácil.

Exemplo prático do Princípio da Responsabilidade Única

Esse é um exemplo retirado do livro: Mergulho nos Padrões de Projetos, de Alexander Shvets. Para facilitar, traduzi o exemplo para Python.

Observe como essa classe viola o Princípio da Responsabilidade Única: além de armazenar os dados do funcionário, ela também esta gerando um relatório:

class Employee:
    def __init__(self, name, salary):
        self.name = name
        self.salary = salary

    def printTimeSheetReport(self):
        return f"Report: {self.name} - Salary: R${self.salary}"

Se a lógica do relatório mudar, a classeEmpregadotambém terá que sofrer modificações, isso é um sinal de que ela está abraçando mais de um papel. A solução? Dividir em duas classes:

class Employee:
    def __init__(self, name, salary):
        self.name = name
        self.salary = salary

class TimeSheetReport:
    def __init__(self, employee):
        self.employee = employee

    def printReport(self):
        return f"Report: {self.employee.name} - Salary: R${self.employee.salary}

Agora, a classe Employee lida apenas com os dados do funcionário, e TimeSheetReport é responsável por gerar o relatório. Cada classe tem um único objetivo, respeitando o SRP.

Como saber se uma classe só tem um objetivo

Saber se uma classe segue o SRP pode ser um trabalho difícil, mas algumas perguntas podem te ajudar nesse processo:

• Eu consigo descrever o que essa classe faz em uma frase simples, sem usar a palavra “e”?
• Se eu fosse escrever um teste para essa classe, ele testaria mais de um comportamento?
• Alguma função dessa classe poderia ser removida ou trocada sem afetar o restante?

Se a resposta for “sim” para uma ou mais dessas questões, é bem provável que sua classe não siga o Princípio da Responsabilidade Única

Existe um tamanho ideal para uma classe?

Essa é uma dúvida comum — e eu mesma já tive! A verdade é que o tamanho da classe (em número de linhas) não define se ela está boa ou ruim.

Uma classe pode ter muitas linhas e ainda assim seguir o SRP, ou ser bem pequena e acumular responsabilidades. O que realmente importa, como já discutimos antes, é se ela está focada em um único propósito.

Em busca de mais conhecimento?

Se você quer aprender mais sobre princípios SOLID, boas práticas de programação e padrões de design, recomendo visitar o site Refactoring Guru. Lá você encontra explicações visuais, exemplos de código e diversos conteúdos que vão te ajudar a escrever códigos melhores.

Além disso, aqui está o link para o PDF do livro “Agile Software Development, Principles, Patterns, and Practices” do Robert C. Martin — uma leitura essencial para quem quer dominar o assunto!