PRINCÍPIO DA RESPONSABILIDADE ÚNICA

PRINCÍPIO DA RESPONSABILIDADE ÚNICA

Em Inglês: SINGLE RESPONSIBILITY PRINCIPLE (SRP)

Uma classe deve ter um, e exclusivamente um, motivo para ser alterada.

Ou seja, não devemos ter uma única classe fazendo de tudo: recebendo dados, validando requisições, aplicando regras de negócio e acessando o banco de dados...

Essa classe que “faz tudo” é a famosa God Class, e é um anti-pattern.

É MESMO TÃO IMPORTANTE?

Uma analogia que explica bem a importância, é a comparação entre Canivete Suíço vs. Bisturi.

Eu sei que pode soar esquisito de primeira, mas vamos destrinchar. Um canivete até pode ser bem útil, carregando um monte de funcionalidades de uma vez, sendo prático no dia a dia.

Mas e se uma ferramenta dele quebrar?

PONTO PARA ESPECIALIZAÇÃO

Você vai ter que comprar outro, mesmo que todas as outras ferramentas estejam funcionando bem. Um desperdício né? Isso aplicado em software fica pior ainda.

Já o bisturi, além de ter menos possibilidades de quebrar, ele é especialista na própria função. Você só vai trocar o bisturi, se ele realmente tiver algum problema.

CONEXÃO COM ARQUITETURA

Na prática, o SRP é a base para organizar a estrutura do seu projeto.

Uma classe que só atende a uma única responsabilidade ajuda na compreensão de arquiteturas como MVC, Hexagonal, Clean Arch...

Esse princípio determina que não faz sentido você ter uma classe que define atributos, valida campos, salva dados no banco... Nesse cenário, a classe assumiria múltiplas responsabilidades, o que viola os preceitos de qualquer uma dessas arquiteturas.

UM MAU EXEMPLO

Essa classe abaixo cumpre mais de uma responsabilidade. Uma classe que lida com persistência, validação, regras de negócio... fere o SRP.

Exemplo de Código (O Anti-pattern):

class UserService {

  constructor(

    private name: string,

    private email: string,

  ) {}



  // Responsabilidade 1: Validação de Dados

  public validateEmail(): boolean {

    return this.email.includes("@");

  }



  // Responsabilidade 2: Persistência de Dados (Acesso ao Banco de Dados)

  public saveToDatabase(): void {

    console.log(`Saving user ${this.name} to MySQL database...`);

  }



  // Responsabilidade 3: Envio de Notificações

  public sendWelcomeEmail(): void {

    console.log(`Sending welcome email to ${this.email}...`);

  }



  // Responsabilidade 4: Geração de Relatórios (Apresentação/Visualização)

  public generateUserReportPDF(): void {

    console.log(`Generating PDF report for ${this.name}...`);

  }



  // Responsabilidade 5: Infraestrutura (Log de Erros)

  public logSystemError(error: string): void {

    console.log(`[LOG] ${new Date().toISOString()}: ${error}`);

  }

}

E O QUE SERIA UM BOM EXEMPLO?

Seria extrair todas essas responsabilidades (Persistência, Regra de Negócio, Validação, Fronteira...) de uma única classe.

E justamente por isso, o SRP conversa tão bem com arquiteturas e suas camadas. Usando a famosa "Clean Arch" como exemplo, cada uma de suas camadas vai assumir uma responsabilidade bem definida.

Exemplo de Código (Aplicando o SRP):

// ✅ SOLID: Cada classe tem apenas um motivo para mudar



class UserValidator {

  public isValidEmail(email: string): boolean {

    return email.includes("@");

  }

}



class UserRepository {

  public save(user: User): void {

    console.log(`Saving user ${user.name} to database...`);

  }

}



class EmailService {

  public sendWelcomeEmail(email: string): void {

    console.log(`Sending welcome email to ${email}...`);

  }

}



class ReportGenerator {

  public generateUserPDF(user: User): void {

    console.log(`Generating PDF report for ${user.name}...`);

  }

}



class Logger {

  public logError(error: string): void {

    console.log(`[LOG] ${new Date().toISOString()}: ${error}`);

  }

}

SRP + CLEAN ARCH

Cada camada cumpre apenas sua responsabilidade e repassa para a próxima camada, seguindo o fluxo. O detalhe é que, dependendo do tamanho do projeto, da equipe e das necessidades, as camadas podem aumentar ou diminuir.

• 
  ROUTE: Recebe a requisição HTTP e direciona o tráfego.


• 
  CONTROLLER: Valida os dados de entrada e formata a resposta final.


• 
  SERVICE: Orquestra as regras da aplicação e as entidades.


• 
  REPOSITORY: Isola o banco de dados e executa a persistência.

OUTROS CASOS

O exemplo anterior focou em Clean Arch, mas outras abordagens arquiteturais, como MVC e Hexagonal, também aplicam o SRP em suas bases.

O SOLID atua como um alicerce para esses padrões, não como um concorrente.

Na prática, a divisão de responsabilidades acaba ficando implícita na própria definição das camadas de qualquer boa arquitetura:

⬇️ user.route.ts

⬇️ user.controller.ts

⬇️ user.service.ts

⬇️ user.repository.ts

Meus Links

Github:

Portfólio:

Deixe sua reação ❤️

Você já tinha percebido a importância do SRP?