The Single Responsibility Principle
MARTIN, R. C. The Single Responsibility Principle. Clean Code Blog https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html (2014).
O artigo discute o Princípio da Única Responsabilidade (Single Responsibility Principle - SRP) no contexto do desenvolvimento de software. Aqui está um resumo em bullet points:
- Em 1972, David L. Parnas publicou um artigo sobre a decomposição de sistemas em módulos.
- Ele enfatizou que os módulos devem ser separados com base em como eles podem mudar.
- Edsger Dijkstra introduziu o termo “Separação de Preocupações” (Separation of Concerns) em um artigo posterior.
- Durante os anos 1970 e 1980, surgiram muitos princípios de arquitetura de software, incluindo noções de Acoplamento e Coesão.
- No final dos anos 1990, o autor consolidou essas noções no Princípio da Única Responsabilidade.
- O SRP afirma que cada módulo de software deve ter apenas uma razão para mudar.
- Há questionamentos sobre o que define uma “razão para mudar”.
- Bug-fixes e refatorações não são considerados razões para mudar em relação ao código, mas sim responsabilidades do programador.
- O artigo sugere que a responsabilidade do código está ligada a quem ele é responsável.
- Por exemplo, diferentes executivos em uma organização têm diferentes responsabilidades e, portanto, diferentes razões para solicitar mudanças em um software.
- O SRP é, em última análise, sobre pessoas.
- Quando mudanças são solicitadas em um módulo de software, essas mudanças devem originar-se de uma única pessoa ou grupo de pessoas.
- A ideia central é isolar módulos das complexidades da organização e garantir que cada módulo responda às necessidades de apenas uma função de negócios.
- O artigo enfatiza a importância de separar preocupações para evitar confusões e erros que podem surgir quando diferentes partes do código são misturadas.
- Outra formulação do SRP é:
- Agrupar juntos as coisas que mudam pelas mesmas razões e separar aquelas que mudam por razões diferentes.
- O SRP também pode ser visto como uma maneira de definir coesão e acoplamento no desenvolvimento de software.