SRP – Princípio da Responsabilidade Única, você sempre entendeu errado

O famoso princípio da responsabilidade única (Single Responsibility Principle), “o S do SOLID”. O mais difundido e o mais mal interpretado de todos.

Primeiramente, vamos ao que é SOLID.

Segundo nosso “querido” Tio Bob:

“Os princípios SOLID nos dizem como organizar as funções e estruturas de dados em classes e como essas classes devem ser interconectadas…”.

Entenda como a estrutura por traz do seu software ou em que pastas eles devem ficar. Calma, to brincando, mas nem tanto.

Ainda segundo o Tio, tudo isso para que tenhamos softwares que:

• Sejam tolerantes a falhas;
• Sejam fáceis de entender;
• Sejam a base de componentes que possam ser usados em muitos sistemas de software.

Simplificando, para que você consiga deixar seu coleguinha feliz quando ele for da manutenção no mostro que criou e que seu código possa ser reutilizado como modulo.

Vamos falar sobre o primeiro acrônimo o S Single Responsibility Principle (SRP).

Afinal o que é SRP?

Segundo a historia, SRP é:

“Um modulo deve ter uma, e apenas uma, razão para mudar”.

Você leu bem, modulo. Falo sobre isso um pouco mais abaixo.

Mas então quando eu coloco classes e funções que fazem somente uma coisa ela sem enquadra nisso? Então é SRP? Sim e Não.
Sim, para o conceito de que classes e funções devem fazer apenas uma coisa. Facilita muito o código, mas isso somente não é o que diz esse princípio.

Segundo o Tio:

“Um módulo deve ser responsável por um, e apenas um, usuário ou stakeholder”

Entenda usuário e stakeholder como Atores ou responsáveis por aquele modulo. Entenda modulo como o conjunto de classes e funções que atendem a demanda dos Atores. Agora não sei se piorei ou melhorei o negócio. 🙂

Mas juntando as duas coisas, quem deve ser responsável pela mudança é o Ator (Deparmento, Usuario, Stakeholder) que representa aquele modulo.

Um exemplo. 

Vamos imaginar o tradicional sistemas de Estoque.

Imagine o sistema feito pelo seu sobrinho que aprendeu programação a 5 meses atras e ganha 5k por mês. So pra dar uma descontraída.

Veja que nesse exemplo, temos dois atores de contextos ou cenários ou departamentos diferentes “brigando” pelo Cadastrar Produtos. Qualquer alteração no Cadastro de Produtos solicitada pela estoquista pode gerar problemas para o compras e vice e versa. É nesse sentido que se entra o SRP e a separação dos módulos. 

Veja o caso de uso abaixo: 

Nesse contexto teremos dois módulos. O Estoque e o Compras e para cada modulo teríamos o “Cadastrar Produtos” com dados, validações, tabelas e até banco de dados diferentes.

Mas Dumbá, você quer que eu duplique a classe de produtos ou pior a tabela? Não seria redundante? Outra vez sim e não. Essa separação de contexto é muito descrita no DDD para contextos delimitados e serve de base para Microsserviços. 

Sim, seria muito interessante duplicar, pois o Produto que o estoquista precisa é “diferente”, veja bem as aspas, pois o diferente é em contexto de software e não fisicamente, do que o compras precisa, mas se não estiver preparado para tal complexidade, estenda a classe Produto ou utilize de um padrão chamado Facede. Assim você terá basicamente a mesma estrutura de produtos genérica e as especialidades de cada Ator separadas.  

Assim, qualquer mudança feita para um Ator não afeta o outro Ator, garantindo assim o que o SOLID prega, que. 

• Sejam tolerantes a falhas;
• Sejam fáceis de entender;
• Sejam a base de componentes que possam ser usados em muitos sistemas de software.

Tentei explicar de uma forma mais simples o que Tio Bob quis dizer com isso. Não se baseie somente nesse artigo, pois é um resumo do resumo. Leia o livro Arquitetura Limpa e complemente seu conhecimento. Tem muita gente ensinando esse principio errado, mas o errado também esta certo, só que em outro principio. (Me compliquei todo aqui!)

Obrigado pela leitura e dúvidas ja sabe! Concordou com nada, pode mandar ai também. 

Software de Qualidade é aquele que tem o cliente satisfeito.

Bibliografia

Arquitetura Limpa, Robert C Matin, 2019.

Facede: https://pt.wikipedia.org/wiki/Façade

DDD: https://en.wikipedia.org/wiki/Domain-driven_design

Microsservicos: https://microservices.io/