Single Responsibility Principle
Cada coisa faz só uma tarefa
Uma classe/função deve ter apenas uma razão para mudar.
Explicando como se você tivesse 5 anos
Agora sim! 🎉
Uma tesoura corta, um lápis escreve. Se você tentar fazer uma tesoura que também escreve, vai ficar ruim nas duas coisas!
Por que isso é uma Red Flag?
Atenção ao problema! ⚡
Quando classes ou funções violam SRP fazendo múltiplas coisas não relacionadas, o código torna-se frágil e difícil de manter. Mudanças em uma responsabilidade podem quebrar outras. Indica falta de coesão e design mal pensado. A oportunidade é refatorar em módulos menores e focados, cada um com uma única razão para mudar.
Para que serve
Manter o código focado e fácil de manter, com cada módulo tendo uma única responsabilidade.
Explicação Detalhada
O Princípio da Responsabilidade Única afirma que uma classe deve ter apenas uma razão para mudar, ou seja, apenas uma responsabilidade. Isso não significa fazer apenas uma coisa, mas que todas as coisas que faz devem estar relacionadas a uma única responsabilidade. Exemplo ruim: uma classe User que valida, persiste e envia email. Exemplo bom: User, UserValidator, UserRepository, EmailService.
História
Uncle Bob formulou o SRP como parte dos princípios SOLID. Ele percebeu que código que faz muitas coisas diferentes muda com frequência e por razões diferentes, tornando-se frágil.
Quem Inventou
Robert C. Martin (Uncle Bob)
Ano: 2000
Compartilhar
Relacionadas
Open/Closed Principle
Aberto para extensão, fechado para modificação
Liskov Substitution Principle
Subtipos devem ser substituíveis por seus tipos base
Interface Segregation Principle
Não obrigue ninguém a depender do que não usa
Dependency Inversion Principle
Dependa de abstrações, não de implementações concretas
Explicando como se você tivesse 5 anos
Agora sim! 🎉
Uma tesoura corta, um lápis escreve. Se você tentar fazer uma tesoura que também escreve, vai ficar ruim nas duas coisas!
Por que isso é uma Red Flag?
Atenção ao problema! ⚡
Quando classes ou funções violam SRP fazendo múltiplas coisas não relacionadas, o código torna-se frágil e difícil de manter. Mudanças em uma responsabilidade podem quebrar outras. Indica falta de coesão e design mal pensado. A oportunidade é refatorar em módulos menores e focados, cada um com uma única razão para mudar.
História
Uncle Bob formulou o SRP como parte dos princípios SOLID. Ele percebeu que código que faz muitas coisas diferentes muda com frequência e por razões diferentes, tornando-se frágil.
Quem Inventou
Robert C. Martin (Uncle Bob)
Ano: 2000
Para que serve
Manter o código focado e fácil de manter, com cada módulo tendo uma única responsabilidade.
Explicação Detalhada
O Princípio da Responsabilidade Única afirma que uma classe deve ter apenas uma razão para mudar, ou seja, apenas uma responsabilidade. Isso não significa fazer apenas uma coisa, mas que todas as coisas que faz devem estar relacionadas a uma única responsabilidade. Exemplo ruim: uma classe User que valida, persiste e envia email. Exemplo bom: User, UserValidator, UserRepository, EmailService.
Heurísticas Relacionadas
Open/Closed Principle
Aberto para extensão, fechado para modificação
Liskov Substitution Principle
Subtipos devem ser substituíveis por seus tipos base
Interface Segregation Principle
Não obrigue ninguém a depender do que não usa
Dependency Inversion Principle
Dependa de abstrações, não de implementações concretas
Fontes e Referências
Quer se aprofundar? Confira essas fontes oficiais: