SOLID - Princípio da responsabilidade única

Três definições para o princípio da responsabilidade única.

SOLID - Princípio da responsabilidade única

O Princípio da Responsabilidade Única pode ser definido por três conceitos-chave:

Cada classe deve ter apenas uma responsabilidade: Uma classe deve ser projetada para ter uma única responsabilidade e não deve ser sobrecarregada com múltiplas tarefas ou funcionalidades. Isso promove um design de software mais coeso, facilitando a compreensão, manutenção e reutilização do código.

Uma classe deve ter um, e apenas um, motivo para mudar: Uma classe deve ser modificada apenas quando houver uma alteração relacionada à sua responsabilidade principal. Se uma classe é responsável por várias funcionalidades, qualquer mudança em uma delas pode afetar todo o código da classe, tornando-o mais propenso a erros e dificultando a manutenção.

Uma classe deve ser responsável por um, e apenas um, ator: Cada classe deve ter um papel bem definido e estar focada em atender às necessidades de um ator específico no sistema. Isso garante que as classes sejam altamente coesas e não assumam responsabilidades que não lhes pertencem.

Sintomas de códigos que não aderem ao Princípio da Responsabilidade Única:

  • Efeitos colaterais: Classes com múltiplas responsabilidades tendem a causar efeitos colaterais indesejados, resultando em bugs e comportamentos imprevisíveis. A aderência ao SRP ajuda a reduzir esse risco, melhorando a qualidade e confiabilidade do software.
  • Merges conflituosos: Quando diferentes desenvolvedores trabalham em uma base de código que contém classes com múltiplas responsabilidades, é mais provável que ocorram conflitos e dificuldades durante o processo de merge. O SRP facilita a colaboração e o trabalho simultâneo, uma vez que cada classe tem um foco claro e uma única responsabilidade.

O objetivo da aplicação do Princípio da Responsabilidade Única é separar as responsabilidades de cada classe, resultando em código mais coeso, legível e de fácil manutenção. Ao seguir esse princípio, é possível reduzir os efeitos colaterais, melhorar a testabilidade, facilitar a evolução do sistema e aumentar a satisfação de todos os envolvidos no desenvolvimento e uso do software.

Grande abraço! 

 Para saber mais: