SOLID: Entendendo o Princípio da Responsabilidade Única (SRP)

Solid é um acrônimo da língua inglesa em que cada letra representa um princípio de design a ser respeitado no paradigma orientado a objetos (POO). Os princípios, juntos, auxiliam na manutenibilidade, flexibilidade e entendimento do código em POO no geral. SRP é o primeio principio do SOLID.

SRP - Single Responsibility Principle

Apesar do nome, esse princípio não está relacionado com um módulo realizar apenas uma coisa e uma coisa muito bem, mas sim à coesão e aos “clientes” da classe.

No dicionário, coesão significa: “unidade lógica, coerência de um pensamento, de uma obra.” Em desenvolvimento de software, coesão é vista como a responsável pela separação de módulos e classes. Fazendo analogia com o mundo real, qual o sentido de uma impressora numa pessoa? Não faz sentido, certo? A ideia é a mesma em POO. Uma classe deve conter propriedades relacionadas à sua existência num sentido lógico. Uma classe de Pessoa pode conter dados e talvez validações de Pessoa, mas não a habilidade de imprimir formulários. Coesão pode ser aplicada a todos os níveis: módulos, classes e funções.

Além da coesão, também devemos considerar um único ator responsável por determinada classe ou módulo. O ator é basicamente o usuário, stakeholder ou grupo interessado em mudanças nessa classe.

O exemplo acima mostra uma clara violação do SRP, pois a classe Apólice possui vários motivos para mudar, sendo eles:

• Cliente: Ator interessado na impressão ou exibição da carteirinha.
• Usuário: Interessado em realizar uma ação no sistema, como cancelar uma apólice. Nesse caso, o usuário pode englobar o próprio cliente, funcionário da Seguradora ou ação do sistema. Ações sobre a Apólice como essa podem envolver inúmeras regras de negócio e podem mudar ao longo do desenvolvimento.
• DBA: Alterações relacionadas à persistência geralmente são de responsabilidade de um DBA ou Desenvolvedor. Uma mudança no Schema não tem relação com políticas de cancelamento de apólice, por exemplo.

Como demonstrado acima, três atores podem trazer motivos diferentes para mudança na entidade Apólice. Esse nível de acoplamento atrapalha no processo de desenvolvimento e manutenção do sistema, visto que times trabalhando em projetos diferentes podem impactar uns aos outros.

Solução

Existem várias formas de abordar o problema de múltipla responsabilidade. Abaixo, um exemplo:

O nome das classes deixa clara a sua intenção. O método “cancelarApólice” permanece na apólice por se tratar de um modelo “Rico”.

Conclusão

O Princípio da Responsabilidade Única é uma ferramenta poderosa para criar um código mais limpo, organizado e fácil de manter. Ao separar as responsabilidades e garantir que cada classe ou módulo tenha apenas um motivo para mudar, reduzimos o acoplamento e aumentamos a coesão do sistema. Isso facilita a colaboração entre diferentes partes da equipe e torna o código mais resiliente às mudanças. Compreender e aplicar o SRP é um passo fundamental para qualquer desenvolvedor que busca escrever um código mais eficiente e eficaz.