SRP — Single Responsability Principle
Quando ecoa que devemos ter classes, funções ou módulos com apenas uma responsabilidade parece que escutamos o Tio Bob lá atrás em sua sala falando algo similar a isto: “Bah! Ou ele não entendeu direito ou este é um princípio de fato confuso”. É praticamente unânime entre todos os leitores que este princípio é um dos mais difíceis de entender. Vejamos:
“… a melhor estrutura para um sistema de software deve ser altamente influenciada pela estrutura social da organização que o utiliza, de modo que cada módulo de software tenha uma, e apenas uma, razão para mudar”.
Como procedemos? Vamos seguir afirmando que não entendemos ou vamos tentar encontrar neste princípio um conselho infalível para seguirmos pelo bom caminho, ainda que com alguma dúvida?
Depois de uma pausa para o café creio que a melhor opção é seguirmos com o que entendemos. Existem ao menos alguns micro-conselhos que podemos abstrair deste princípio. Creio que podemos operar da seguinte maneira:
“Uma classe, uma função, um módulo ou um simples elemento em um código deve fazer apenas uma tarefa, e esta tarefa deve ser feita apenas em favor de um ator. Entenda-se: A única razão para algo mudar é pela manifestação da vontade de seu ator/cliente. Do contrário, tudo deve permanecer como está”.
No exemplo abaixo vemos claramente que existem muitos motivos e muitos objetivos para uma mesma classe. Será que é possível dar conta de tudo isto?
Tio Bob nos alerta que este é um dos princípios mais difíceis de se entender, no entanto, nós devemos de qualquer maneira tentar aprender alguma coisa.
É natural que o entendimento seja difícil, mas isto não deve ser tomado como impossível. O que podemos extrair ao menos neste primeiro momento são os seguintes conselhos:
- Separar os elementos (classes, funções, módulos), preferencialmente, em arquivos diferentes;
- Passar e receber informações entre classes de diferentes responsabilidades;
- Cada elemento deve atender unicamente ao seu ator;
- Manter a coesão entre elementos que atendam a um mesmo ator;
- Evitar o acoplamento pela separação de tarefas de um mesmo ator seja em um contexto ou em um domínio;
Vale lembrar que o ápice deste conselho é que cada elemento faça algo unicamente para um ator e nada mais. Nos exemplos utilizados em seu livro o Tio Bob alerta para duas situações comuns que são os problemas comuns especialmente para quem inicia no mundo do software:
- Criação de “God Class”, ou seja, classes que atendam a N atores;
- Fusões de códigos porque vários elementos de diferentes atores estão acoplados;
No frigir dos ovos meu palpite é tentar seguir pelo caminho do aprendizado fazendo testes, porém, seguindo o que conseguimos extrair de melhor deste princípio. Não tenha medo de errar e siga em frente. Este talvez seja o principal conselho que recebemos de herança das andanças do Tio Bob.
Inclusive, não há motivo para se arrancar os cabelos neste momento. Com a chegada lá adiante da Arquitetura Limpa tudo isto que falamos fará mais sentido e terá um contexto muito melhor de aplicação.
Repito: Não seja um xiita no seu dia-a-dia. Na dúvida converse com seus pares para estabelecer leituras coletivas sobre o assunto. Leitura e diálogo é sempre muito produtivo e te digo uma bem boa: é bonito ler o livro do Tio Bob, porém, seria muito bem mais interessante poder conversar com ele pessoalmente!
Te agradeço a leitura.
Caso queira seguir "no proseio" sobre o tema você pode me encontrar aqui:
https://www.linkedin.com/in/alexandre-klock-ernzen-5484319/
Bons estudos!
Artigos sobre SOLID:
Introdução > https://medium.com/@bracinho2/solid-introdu%C3%A7%C3%A3o-6b4dbdacdb87
S > https://medium.com/@bracinho2/srp-single-responsability-principle-8d9a68bbae76
O > https://medium.com/@bracinho2/ocp-open-closed-principle-cc21cb168707
