7. SRP: Princípio da Responsabilidade Única
Um módulo deve ser responsável por um, e apenas um, ator.
Resumo
- SRP não é "fazer uma só coisa" (isso vale para funções).
- Definição: um módulo responde a um, e apenas um, ator (grupo de stakeholders).
- Sintoma 1: duplicação acidental. Mudança do CFO quebra relatório do COO via código compartilhado.
- Sintoma 2: merges. Times diferentes alteram o mesmo arquivo e colidem.
- Solução: separar dados de funções; classes por ator + Facade para reunir. Nível componente: CCP; nível arquitetura: eixo de mudança.
Perguntas-chave
responda de cabeça, depois abraQual a definição final do SRP?
Um módulo deve ser responsável por um, e apenas um, ator.
O que é duplicação acidental?
Código compartilhado entre atores diferentes. Mudança pedida por um quebra o outro sem ninguém perceber.
Como resolver violação de SRP sem espalhar o uso?
Separar em classes por ator e oferecer um Facade que delega para elas.
Exercícios de fixação
0/5 respondidas1.
Qual a definição correta do SRP no livro?
2.
A classe Employee tem
calculatePay() (CFO), reportHours() (COO) e save() (CTO). Ambos os cálculos usam regularHours(). O CFO pede mudança nas horas regulares. Qual o risco?3.
Dois times editam o mesmo arquivo por motivos diferentes e sofrem com conflitos de merge. Que princípio foi violado?
4.
Qual padrão o autor sugere para reunir classes separadas por ator em um único ponto de acesso?
5.
No nível de componentes e arquitetura, o SRP reaparece como: