Disclaimer
Este texto foi inicialmente concebido pela IA Generativa em função da transcrição do episódio do nosso canal, Dev Eficiente. O episódio completo pode ser visto no canal.
Introdução
O Princípio da Responsabilidade Única (Single Responsibility Principle - SRP) é um dos pilares do SOLID, um conjunto de princípios de design de software que visa melhorar a qualidade e a manutenção do código. O SRP, em particular, foca em garantir que cada módulo ou classe em um sistema tenha uma única responsabilidade bem definida. Neste post, vamos explorar como aplicar esse princípio de maneira prática e eficiente no seu dia a dia de desenvolvimento.
O Que é o Princípio da Responsabilidade Única?
O SRP pode ser resumido pela frase: "Mantenha juntas as coisas que mudam pelo mesmo motivo e separe as que mudam por motivos diferentes." Isso significa que, ao projetar um sistema, devemos agrupar funcionalidades que estão relacionadas e separar aquelas que não estão. Parece simples, mas na prática, pode ser um desafio.
Por exemplo, imagine que você está desenvolvendo um sistema com várias camadas, como a interface do usuário, a lógica de negócios e a comunicação com serviços externos. Cada uma dessas camadas deve ser separada, pois elas mudam por razões diferentes. A interface do usuário pode mudar devido a uma nova exigência de design, enquanto a lógica de negócios pode mudar devido a uma nova regra de negócio. Separar essas responsabilidades ajuda a manter o código mais organizado e fácil de manter.
A Parte Fácil e a Parte Difícil
A parte mais fácil de aplicar o SRP é quando estamos lidando com camadas bem definidas, como separar a interface do usuário da lógica de negócios. No entanto, a maior parte do tempo, você estará lidando com regras de negócios complexas, e é aí que as coisas ficam mais complicadas. Quando você está codificando essas regras, pode ser difícil decidir onde exatamente separar as responsabilidades.
Por exemplo, ao criar um novo microserviço, até onde vai a responsabilidade desse serviço? Ou, ao criar uma nova classe, quais operações e atributos devem estar nela? Essas são decisões que você precisa tomar constantemente, e é fácil acabar misturando responsabilidades sem perceber.
Como Minimizar a Mistura de Responsabilidades
Nitidez sobre o problema sendo resolvido
Embora seja inevitável que, em algum momento, você acabe misturando responsabilidades, existem maneiras de minimizar isso. A primeira coisa que você precisa é nitidez sobre o problema que está resolvendo. Seja uma classe, um módulo ou um microserviço, você deve ter clareza sobre qual problema aquele pedaço de código está resolvendo. Isso ajuda a manter o foco e evitar que você adicione funcionalidades que não pertencem àquela responsabilidade.
Busque por coesão
Outro ponto importante é manter a coesão. As unidades de código devem estar relacionadas entre si. Por exemplo, os métodos de uma classe devem operar sobre os atributos dessa classe. Se um método não usa nenhum atributo da classe, talvez ele não devesse estar ali. Isso ajuda a garantir que a classe tenha uma única responsabilidade(mesmo que de vez em quando seja responsabilidade demais).
Evite o acoplamento mental
Além disso, é importante evitar o que chamamos de acoplamento mental. Isso acontece quando você deixa que o conhecimento sobre como outro time ou serviço vai consumir o seu código influencie suas decisões de design. O foco deve estar no problema que você está resolvendo em como você planeja oferecer isso e não em como o código será consumido por outros. Já sabe né? Quem quer agradar todo mundo acaba não agradando ninguém.
Métricas para Avaliar o SRP
Para tornar a aplicação do SRP mais objetiva, você pode usar algumas métricas. Por exemplo, o acoplamento é uma métrica que mede o quanto uma classe depende de outras. Se o acoplamento está aumentando, pode ser um sinal de que a classe está assumindo mais responsabilidades do que deveria.
Outra métrica útil é o fan-out, que mede quantas outras classes uma classe está chamando. Se uma classe está chamando muitas outras, isso pode indicar que ela está fazendo mais do que deveria.
Você também pode usar métricas de coesão, como o Lack of Cohesion of Methods (LCOM), que mede o quanto os métodos de uma classe estão relacionados aos seus atributos. Se os métodos não estão usando os atributos da classe, isso pode ser um sinal de que a classe está assumindo responsabilidades que não deveria.
Sistematizando a Aplicação do SRP
Uma maneira de facilitar a aplicação do SRP é sistematizar o processo. Isso pode ser feito criando guidelines e checklists que ajudem a equipe a seguir boas práticas de design. Por exemplo, você pode criar um checklist com as métricas mencionadas acima e usá-lo durante as revisões de código. Isso ajuda a garantir que o princípio da responsabilidade única seja aplicado de forma consistente em todo o projeto.
Além disso, sistematizar o processo facilita o reuso do conhecimento e ajuda a criar uma visão crítica sobre a aplicação do SRP. Quando você tem um guideline claro e um checklist quantitativo, fica mais fácil identificar quando uma responsabilidade está sendo misturada e tomar ações para corrigir isso. Inclusive fica mais fácil de perceber quando determinado guideline não está direcionando a qualidade para o patamar desejado.
Conclusão
Aplicar o Princípio da Responsabilidade Única pode parecer simples à primeira vista, mas na prática, envolve uma série de decisões complexas. No entanto, com clareza sobre o problema, foco na coesão e uso de métricas objetivas, você pode minimizar a mistura de responsabilidades e criar um código mais organizado e fácil de manter. Além disso, sistematizar o processo com guidelines e checklists pode ajudar a garantir que o SRP seja aplicado de forma consistente em toda a sua organização.
Vamos falar mais ?
Se você gostou, deixa um comentário aqui. Tem um comentário construtivo? Deixa aqui também, com educação. Vamos trocar mais ideias :).
Conheça mais sobre a Jornada Dev + Eficiente
A Jornada Dev + Eficiente é um treinamento cujo objetivo é fazer com que você cresça na carreira como uma pessoa especialista em Design e Arquitetura de Software.
Para saber mais, acesse em https://deveficiente.com
Top comments (0)