O princípio da responsabilidade única
O princípio da responsabilidade única (do inglês SRP: single-responsibility principle) é um princípio de programação de computadores que estabelece que "Um módulo deve ser responsável por um, e apenas um, ator."[1] O termo ator refere-se a um grupo (composto por uma ou mais partes interessadas ou usuários) que requer uma mudança no módulo.
Robert C. Martin, o criador do termo, expressa o princípio como: "Uma classe deve ter apenas um motivo para mudar".[2] Devido à confusão em torno da palavra "motivo", ele mais tarde esclareceu seu significado em uma postagem de blog intitulada "The Single Responsibility Principle", na qual mencionou a Separação de conceitos e afirmou que "Outra forma de expressar o Princípio da Responsabilidade Única é: Reúna as coisas que mudam pelos mesmos motivos. Separe aquelas coisas que mudam por motivos diferentes. Em algumas de suas palestras, ele também argumenta que o princípio diz respeito, especificamente, a papéis ou atores. Por exemplo, embora possam ser a mesma pessoa, o papel de um contador é diferente do de um administrador de banco de dados. Portanto, cada módulo deve ser responsável por cada papel.[3]
História
[editar | editar código]O termo foi introduzido por Robert C. Martin em seu artigo "The Principles of OOD" como parte de seus Princípios de Design Orientado a Objetos, e popularizado por seu livro de 2003, Desenvolvimento de Software Ágil, Princípios, Padrões e Práticas.[4] Martin o descreveu como um princípio baseado na coesão, conforme descrito por Tom DeMarco em seu livro Structured Analysis and System Specification,[5] e por Meilir Page-Jones em The Practical Guide to Structured Systems Design.[6] Em 2014, Martin publicou uma postagem de blog intitulada "The Single Responsibility Principle" com o objetivo de esclarecer o significado da frase "motivo para mudar".
Exemplo
[editar | editar código]Martin define uma responsabilidade como um motivo para mudar, e conclui que uma classe ou módulo deve ter um, e apenas um, motivo para ser alterado (e.g. reescrito).
Como exemplo, considere um módulo que monta e imprime um relatório. Imagine que tal módulo possa ser alterado por dois motivos. Primeiro, o conteúdo do relatório pode mudar. Segundo, o formato do relatório pode mudar. Essas duas coisas mudam por causas diferentes. O princípio da responsabilidade única preconiza que esses dois aspectos do problema são, na verdade, duas responsabilidades separadas e, portanto, deveriam estar em classes ou módulos distintos. Seria uma má prática de design acoplar duas coisas que mudam por motivos diferentes e em momentos distintos.
Manter uma classe focada em uma única responsabilidade é importante porque a torna mais robusta. Continuando o exemplo anterior, se houver uma alteração no processo de montagem do relatório, aumenta o risco de que o código de impressão apresente falhas, caso faça parte da mesma classe.
Ver também
[editar | editar código]- Chain of responsibility
- Acoplamento (programação)
- GRASP (design orientado a objeto)
- Ocultação de informação
- SOLID—o "S" em "SOLID" representa o princípio da responsabilidade única
- Separação de conceitos
Referências
[editar | editar código]- ↑ Martin, Robert C. (2018). Clean architecture : a craftsman's guide to software structure and design. Boston: [s.n.] ISBN 978-0-13-449432-6. OCLC 1003645626
- ↑ Martin, Robert C. (2003). Agile Software Development, Principles, Patterns, and Practices. [S.l.]: Prentice Hall. p. 95. ISBN 978-0135974445
- ↑ Robert C. Martin. Clean Architecture: A Craftsman's Guide to Software Structure and Design]year=2018. [S.l.]: Prentice Hall. ISBN 978-0-13-449416-6
- ↑ Martin 2003, pp. 95-98
- ↑ DeMarco, Tom. (1979). Structured Analysis and System Specification. [S.l.]: Prentice Hall. ISBN 0-13-854380-1
- ↑ Page-Jones, Meilir (1988). The Practical Guide to Structured Systems Design. [S.l.]: Yourdon Press Computing Series. p. 82. ISBN 978-8120314825