SRP: o que é, o princípio da responsabilidade única no desenvolvimento

O que é SRP (Single Responsibility Principle)?

SRP (Single Responsibility Principle) é o princípio da responsabilidade única, que afirma: cada classe ou módulo deve ter exatamente um motivo para mudar. Isso não significa que uma classe deve realizar exatamente uma operação. Refere-se a um grupo de ações relacionadas unidas por uma única responsabilidade perante um ator.

Robert Martin reformulou o SRP em termos de atores: uma classe deve mudar apenas a pedido de uma parte interessada ou de um grupo de pessoas. Se dois atores diferentes exigem mudanças na mesma classe, a responsabilidade está mal dividida.

Por exemplo, uma classe Employee que calcula salário (solicitação do departamento de contabilidade) e gera relatórios (solicitação da gerência) viola o SRP. Alterar regras de cálculo pode afetar a geração de relatórios e vice-versa.

Definição formal de SRP

Um módulo deve ter um e apenas um motivo para mudar. O motivo da mudança é determinado por um ator — pessoa ou sistema que inicia o requisito. Se requisitos de diferentes atores levam a mudanças em um mesmo módulo, este viola o SRP.

O conceito de ator torna o SRP uma ferramenta prática de análise arquitetural, não uma recomendação abstrata. Ao projetar um sistema, basta perguntar: “Quem vai pedir para mudar este código?” — se a resposta incluir mais de uma parte interessada, a responsabilidade deve ser dividida.

Como funciona o princípio da responsabilidade única

A responsabilidade única é implementada agrupando métodos que mudam por um mesmo motivo. A classe torna-se um “ponto de coleta” de lógica relacionada, não um “canivete suíço” para todas as ocasiões. Isso simplifica a compreensão do código: o desenvolvedor vê a classe e entende imediatamente seu propósito.

O mecanismo do SRP baseia-se na regra do eixo único de mudança. Se uma funcionalidade pode mudar por razões independentes, ela deve ser extraída para classes separadas. As conexões entre essas classes são construídas através de composição ou delegação.

A violação do SRP manifesta-se em “God Objects” — classes com dezenas de métodos que trabalham com dados diferentes. Uma classe assim é difícil de testar — testar um método requer configurar o ambiente para todos os outros. Mudar uma responsabilidade pode quebrar outra, tornando o código frágil.

Na prática, o SRP ajuda os desenvolvedores a responder à pergunta “onde está este código?” Se cada responsabilidade estiver em sua própria classe, encontrar o arquivo correto leva segundos. Em um projeto Android com arquitetura MVVM, isso significa que UserViewModel é responsável apenas pelo estado da tela do usuário, e UserRepository pela obtenção de dados. Um desenvolvedor procurando lógica de cache vai para UserCacheRepository, não para ViewModel. Tal organização de código acelera a integração de novos membros da equipe e reduz o número de erros durante a refatoração.

Por que SRP é importante no desenvolvimento mobile

O desenvolvimento mobile exige especial modularidade do código. Um Fragment Android ou ViewController iOS frequentemente se torna um “ímã” de lógica: tratamento de toques, chamadas de API, análise de respostas, atualização de UI — tudo em uma classe. O SRP exige separar essas responsabilidades.

Na arquitetura Android, o SRP está incorporado nas recomendações do Google sobre Jetpack: ViewModel é responsável pelo estado da tela, Repository pelos dados, UseCase pela lógica de negócio. Cada componente tem um motivo para mudar. No desenvolvimento iOS, os padrões MVVM e Coordinator seguem a mesma lógica.

Seguir o SRP em projetos mobile traz benefícios mensuráveis: redução de 40-60% no tamanho das classes, menos tempo em revisões de código e menos erros de regressão ao adicionar novas funcionalidades. Módulos isolados são mais fáceis de cobrir com testes unitários e reutilizar em outras telas.

Impacto do SRP nos testes

Os testes unitários de classes que seguem o SRP exigem menos objetos mock e menos configuração. Se uma classe tem uma única responsabilidade, suas dependências são limitadas. O teste verifica um comportamento, não uma combinação de vários cenários não relacionados.

De acordo com o relatório do Google Testing Blog (2023), classes com responsabilidade única mostram 35% mais cobertura de testes em comparação com classes agregadoras. Os desenvolvedores escrevem mais facilmente testes para módulos pequenos e compreensíveis.

Exemplos de SRP em Android e iOS

Vejamos uma classe Android típica que viola o SRP — ela carrega dados, analisa a resposta e atualiza a UI. Após a refatoração, cada responsabilidade é separada em seu próprio componente.

// Violação de SRP: uma classe faz tudo
class BadUserProfileActivity {
    fun loadUser(userId: Int) {
        // Requisição HTTP
        // Análise JSON
        // Atualização de UI
        // Salvar no BD
    }
}

// Após aplicar SRP
class UserRepository {
    fun getUser(userId: Int): User
}

class UserViewModel {
    private val repo: UserRepository
    fun loadUser(userId: Int) { }
}

class UserProfileFragment {
    fun render(user: User) { }
}

Um exemplo semelhante em iOS Swift com separação da camada de rede e exibição:

// Violação de SRP: ViewController gerencia dados e UI
class BadProfileViewController: UIViewController {
    func viewDidLoad() {
        // Requisição URLSession
        // Decodificar JSON
        // Atualizar label
    }
}

// Após aplicar SRP
protocol UserServiceProtocol {
    func fetchUser(id: Int) async throws -> User
}

class ProfileViewModel {
    private let service: UserServiceProtocol
    func loadProfile(id: Int) { }
}

class ProfileViewController: UIViewController {
    func display(user: User) { }
}

A refatoração SRP não complica a arquitetura — ela redistribui a responsabilidade. A quantidade de código pode até diminuir ao eliminar duplicações. Cada nova classe tem um propósito claro e pode ser desenvolvida independentemente.

Composição como alternativa à herança

A composição ajuda a manter o SRP onde a herança cria acoplamentos desnecessários. Em vez de uma superclasse com dezenas de métodos, a subclasse recebe um conjunto de objetos especializados através do construtor. Cada objeto é responsável por sua própria funcionalidade.

No desenvolvimento Android, o padrão Decorator permite adicionar responsabilidades sem modificar a classe original. No iOS, uma cadeia de Middleware na camada de rede separa logging, cache e autenticação em módulos independentes.

Violações típicas de SRP e suas consequências

A violação mais comum é uma “God Class”: uma classe que gerencia o banco de dados, envia notificações, gera relatórios e processa a entrada do usuário. Essa classe torna-se um gargalo do projeto: qualquer alteração exige testes de regressão completos.

No desenvolvimento mobile, a violação do SRP surge ao misturar lógica de negócio e lógica de UI em Activity, Fragment ou ViewController. Quando um onClickListener simultaneamente valida dados, chama a API e atualiza a visibilidade dos botões — isso é uma violação direta do princípio da responsabilidade única.

As consequências de violar o SRP incluem: dificuldade de desenvolvimento paralelo (conflitos em um único arquivo), testes unitários dificultados, alto custo de modificações e menor legibilidade do código. Projetos com violações sistemáticas de SRP exigem 2-3 vezes mais tempo para adicionar novas funcionalidades.

Indicadores de violação de SRP no código

Podem-se identificar violações de SRP por sinais indiretos: a classe excede 200 linhas, importa módulos de diferentes camadas da aplicação (UI + network + database), tem mais de 5 métodos públicos de diferentes temas. A métrica de coesão é um indicador estatístico: baixa coesão dos métodos dentro de uma classe indica violação de SRP.

Para detectar violações de SRP, utilize ferramentas de análise estática: para Android — Detekt com a regra TooManyFunctions, para iOS — SwiftLint com a regra file_length. Essas utilidades destacam as classes que excedem os limites de tamanho e complexidade.

A refatoração de classes que violam o SRP é feita através de Extract Class ou Extract Delegate: um grupo de métodos relacionados é extraído para uma classe separada e a classe original delega chamadas a eles. A aplicação gradual dessas refatorações transforma uma “God Class” em um conjunto de módulos fracamente acoplados, cada um com uma única responsabilidade. Esta abordagem permite melhorar a arquitetura sem parar o desenvolvimento — a refatoração é feita iterativamente, um módulo de cada vez.