Como Aplicar o Princípio da Responsabilidade Única com Mais Precisão

Disclaimer Este texto foi inicialmente concebido pela IA Generativa em função da transcrição de dois episódios do nosso canal, Dev Eficiente. Se preferir acompanhar por vídeo, é só dar o play. Introdução Entre estes princípios do SOLID, o SRP (Single Responsibility Principle) ou Princípio da Responsabilidade Única é talvez o mais subjetivo e, consequentemente, o mais difícil de aplicar com precisão. Neste post, vamos explorar como você pode implementar o SRP de maneira mais sistemática em seu dia a dia de programação. O que é o Princípio da Responsabilidade Única? Como o próprio "Uncle Bob" Martin já disse de diversas maneiras, a essência do SRP pode ser resumida como: "Mantenha juntas as coisas que mudam pela mesma razão, e separe as coisas que mudam por razões diferentes" (gather together things that change for the same reason, separate things that change for different reasons). À primeira vista, esse princípio parece simples - você agrupa código que deve ser alterado em conjunto e separa o que muda por motivos distintos. Mas na prática, essa aplicação pode se tornar um desafio. A Parte Fácil: Separação por Camadas A aplicação mais comum e relativamente mais simples do SRP é a separação do código em camadas. Por exemplo: Separar o código de domínio do código de framework Isolar a comunicação com serviços externos Separar a interface do usuário da lógica de negócio Segregar os protocolos de entrada e consumo de dados Essa separação permite que você atualize frameworks, modifique camadas de infraestrutura ou altere interfaces sem necessariamente impactar o núcleo da sua aplicação. A Parte Difícil: Quando Não Está Tão Óbvio O verdadeiro desafio surge quando você está trabalhando com a lógica de negócios que fica cada vez mais complexa. Nestes momentos, surgem perguntas como: Até onde vai a responsabilidade de um microserviço? Quais operações e atributos devem estar em uma classe? Quais classes ou funções devem estar em um mesmo pacote ou módulo? O que deve estar contido em um módulo específico da aplicação? Essas são as decisões que compõem a maior parte do seu dia a dia, e é aí que o princípio se torna mais desafiador. É importante lembrar que ter uma única responsabilidade não significa que essa responsabilidade seja simples. Ela pode ser complexa e envolver muitas ações, ou pode ser algo mais pontual. Aceitando a Realidade: Você Vai Misturar Responsabilidades Uma verdade importante: por mais que você se esforce, em algum momento você vai misturar responsabilidades. É como bugs em software - todo código tem bugs, alguns apenas levam mais tempo para serem descobertos. O objetivo não é atingir a perfeição absoluta, mas minimizar as chances de misturar responsabilidades desnecessariamente. Como podemos fazer isso? Estratégias Para Aplicar o SRP Com Mais Precisão 1. Tenha Nitidez Sobre o Problema Você precisa ter clareza absoluta sobre qual problema aquele pedaço de software está resolvendo. Idealmente, isso deve estar documentado em algum lugar: Qual é o objetivo daquele módulo, classe ou microserviço? Quais pessoas ou departamentos estão interessados nessa funcionalidade? Mesmo com essa clareza, erros acontecem. Um exemplo real: em um projeto, foi desenvolvido um serviço para organizar treinamentos e a importação de um treinamento acontecia a partir de um markdown. O código do parser ficava no mesmo serviço. Após a entrega, ficou evidente que o parser não tinha relação direta com a organização de treinamentos e deveria ter sido construído em uma biblioteca separada. 2. Pense na Coesão o Tempo Todo Todas as unidades de código precisam estar relacionadas entre si: Os atributos de uma classe estão coesos? Eles representam o mesmo conceito? Os métodos públicos de uma classe estão relacionados entre si? As abstrações que você está construindo estão alinhadas com o problema que está resolvendo? 3. Evite o Acoplamento Mental Não deixe que seu conhecimento de outros sistemas ou equipes influencie indevidamente seu código. Por exemplo, se você conhece como outra equipe vai consumir seu serviço, não modifique a responsabilidade do seu código por isso. O código deve ser direcionado pelo problema que está resolvendo, não pelo modo como será consumido. Isso evita criar acoplamentos desnecessários que comprometem a responsabilidade única. 4. Use Métricas Quantitativas Para complementar as estratégias qualitativas, você pode observar algumas métricas: Acoplamento: Se o acoplamento está aumentando continuamente, pode ser um sinal de que você está assumindo mais responsabilidades do que deveria. Fan-out: O número de chamadas para outras classes. Uma classe que chama muitas outras pode estar fazendo mais do que deveria. RFC (Response For Class): Quantas chamadas possíveis podem acontecer em função da interface pública da classe. LCOM (Lack of Cohesion of Methods): Se o

Mar 24, 2025 - 02:28

Como Aplicar o Princípio da Responsabilidade Única com Mais Precisão

Disclaimer

Este texto foi inicialmente concebido pela IA Generativa em função da transcrição de dois episódios do nosso canal, Dev Eficiente. Se preferir acompanhar por vídeo, é só dar o play.

Introdução

Entre estes princípios do SOLID, o SRP (Single Responsibility Principle) ou Princípio da Responsabilidade Única é talvez o mais subjetivo e, consequentemente, o mais difícil de aplicar com precisão. Neste post, vamos explorar como você pode implementar o SRP de maneira mais sistemática em seu dia a dia de programação.

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

Como o próprio "Uncle Bob" Martin já disse de diversas maneiras, a essência do SRP pode ser resumida como: "Mantenha juntas as coisas que mudam pela mesma razão, e separe as coisas que mudam por razões diferentes" (gather together things that change for the same reason, separate things that change for different reasons).

À primeira vista, esse princípio parece simples - você agrupa código que deve ser alterado em conjunto e separa o que muda por motivos distintos. Mas na prática, essa aplicação pode se tornar um desafio.

A Parte Fácil: Separação por Camadas

A aplicação mais comum e relativamente mais simples do SRP é a separação do código em camadas. Por exemplo:

Separar o código de domínio do código de framework
Isolar a comunicação com serviços externos
Separar a interface do usuário da lógica de negócio
Segregar os protocolos de entrada e consumo de dados

Essa separação permite que você atualize frameworks, modifique camadas de infraestrutura ou altere interfaces sem necessariamente impactar o núcleo da sua aplicação.

A Parte Difícil: Quando Não Está Tão Óbvio

O verdadeiro desafio surge quando você está trabalhando com a lógica de negócios que fica cada vez mais complexa. Nestes momentos, surgem perguntas como:

Até onde vai a responsabilidade de um microserviço?
Quais operações e atributos devem estar em uma classe?
Quais classes ou funções devem estar em um mesmo pacote ou módulo?
O que deve estar contido em um módulo específico da aplicação?

Essas são as decisões que compõem a maior parte do seu dia a dia, e é aí que o princípio se torna mais desafiador.

É importante lembrar que ter uma única responsabilidade não significa que essa responsabilidade seja simples. Ela pode ser complexa e envolver muitas ações, ou pode ser algo mais pontual.

Aceitando a Realidade: Você Vai Misturar Responsabilidades

Uma verdade importante: por mais que você se esforce, em algum momento você vai misturar responsabilidades. É como bugs em software - todo código tem bugs, alguns apenas levam mais tempo para serem descobertos.

O objetivo não é atingir a perfeição absoluta, mas minimizar as chances de misturar responsabilidades desnecessariamente. Como podemos fazer isso?

Estratégias Para Aplicar o SRP Com Mais Precisão

1. Tenha Nitidez Sobre o Problema

Você precisa ter clareza absoluta sobre qual problema aquele pedaço de software está resolvendo. Idealmente, isso deve estar documentado em algum lugar:

Qual é o objetivo daquele módulo, classe ou microserviço?
Quais pessoas ou departamentos estão interessados nessa funcionalidade?

Mesmo com essa clareza, erros acontecem. Um exemplo real: em um projeto, foi desenvolvido um serviço para organizar treinamentos e a importação de um treinamento acontecia a partir de um markdown. O código do parser ficava no mesmo serviço. Após a entrega, ficou evidente que o parser não tinha relação direta com a organização de treinamentos e deveria ter sido construído em uma biblioteca separada.

2. Pense na Coesão o Tempo Todo

Todas as unidades de código precisam estar relacionadas entre si:

Os atributos de uma classe estão coesos? Eles representam o mesmo conceito?
Os métodos públicos de uma classe estão relacionados entre si?
As abstrações que você está construindo estão alinhadas com o problema que está resolvendo?

3. Evite o Acoplamento Mental

Não deixe que seu conhecimento de outros sistemas ou equipes influencie indevidamente seu código. Por exemplo, se você conhece como outra equipe vai consumir seu serviço, não modifique a responsabilidade do seu código por isso.

O código deve ser direcionado pelo problema que está resolvendo, não pelo modo como será consumido. Isso evita criar acoplamentos desnecessários que comprometem a responsabilidade única.

4. Use Métricas Quantitativas

Para complementar as estratégias qualitativas, você pode observar algumas métricas:

Acoplamento: Se o acoplamento está aumentando continuamente, pode ser um sinal de que você está assumindo mais responsabilidades do que deveria.
Fan-out: O número de chamadas para outras classes. Uma classe que chama muitas outras pode estar fazendo mais do que deveria.
RFC (Response For Class): Quantas chamadas possíveis podem acontecer em função da interface pública da classe.
LCOM (Lack of Cohesion of Methods): Se os métodos da classe realmente usam os atributos da classe ou se estão apenas "morando" lá sem real coesão.

Sistematizando a Aplicação do SRP

A chave para aplicar o princípio da responsabilidade única de forma consistente é a sistematização. Isso pode ser feito através da combinação de:

Guidelines: Direcionamentos qualitativos como os três primeiros pontos acima
Checklists: Verificações quantitativas baseadas nas métricas

Esta sistematização facilita o reuso da linha de pensamento e ajuda na visão crítica sobre a aplicação do princípio. Além disso, torna mais fácil comunicar essas práticas para toda a organização.

É importante revisar periodicamente essas guidelines e checklists. Após um período de aplicação, faça uma retrospectiva: "Como estamos dividindo as responsabilidades? O que está funcionando? O que podemos melhorar?"

Conclusão

A aplicação do Princípio da Responsabilidade Única é uma jornada contínua de aprendizado e melhoria. Não existe uma fórmula perfeita, mas com direcionamentos claros, tanto qualitativos quanto quantitativos, você pode minimizar a mistura indevida de responsabilidades e criar um código mais manutenível e escalável.

Perceba que aplicar o SRP não é necessariamente fácil, mas com esse approach mais sistemático, você terá mais chances de sucesso.

Sobre a Jornada Dev + Eficiente

A Jornada Dev + Eficiente é um treinamento focado em fazer você crescer na carreira como uma pessoa cada vez mais especializada em Entregar Software que Gera Valor com o Máximo de Qualidade e Fluidez.

A Jornada pavimenta este caminho através de uma abordagem integrada, trabalhando diversos aspectos que influenciam na qualidade da entrega final, tais como: Engenharia de Requisitos, Design de Código, Arquitetura, Testes etc. É o único local que você vai encontrar que é 100% focado em fazer você crescer como uma pessoa desenvolvedora de software completa.

Para conhecer mais, acesse https://deveficiente.com