SRP - Princípio de Responsabilidade Única

Uma das bases da programação orientada a objetos é a Coesão. Uma classe é coesa quando ela é focada em uma responsabilidade bem definida, assim como também não tem responsabilidades além da sua. Se uma classe deve gerar uma nota fiscal, por exemplo, essa deve ser a única responsabilidade que ela deve ter e tudo além disso vai diminuir a sua coesão.

É importante termos classes coesas em um projeto orientado a objeto, pois elas apresentam uma série de vantagens, tais como:

• Facilidade de manutenção. Uma vez que temos classes com uma única responsabilidade, saberemos quais classes afetam ou não uma funcionalidade, qual o escopo dessa classes e onde a manutenção e correções de bugs de uma determinada funcionalidade devem ser feitas.

• Menos código. Com menos código, a legibilidade fica mais fácil e podemos ganhar tempo no entendimento do sistema

• Reuso. Uma vez que uma classe cuida de uma única responsabilidade, é fácil reusar sempre que quisermos essa mesma responsabilidade/funcionalidade no sistema, sem que hajam efeitos colaterais.

O Princípio de Responsabilidade Única reforça o uso da coesão, afirmando que se uma classe tem muitas responsabilidades, aumentam as possibilidades de ocorrerem bugs ao alterar uma de suas responsabilidades, sem que possamos perceber. Responsabilidade aqui pode ser definida como um "motivo para mudança" e Robert Martin conclui que "uma classe ou módulo deve ter um, e somente um, motivo para ser alterada" (ou reescrita).

Como exemplo, considere uma classe que compila (coleta dados, realiza processamento, etc.) e imprime um relatório.

class Relatorio {
  public void compilarRelatorio() {
    // Lógica de compilar o relatório
  }

  public void imprimirRelatorio() {
    // Lógica para montar o relatório no formato de impressão escolhido
  }
}

Essa classe pode ser alterada por 2 motivos:

1. O conteúdo e as fontes para compilação do relatório podem mudar

2. O formato do relatório impresso pode mudar

Essas duas motivações para alterações acontecem por causas muito distintas. Uma por questões de lógica e outro por questões estéticas. O Princípio de Responsabilidade Única diz que esses dois aspectos, na prática, são duas responsabilidades separadas, por mais que estejamos trabalhando com a geração de um relatório. Sendo assim, devem estar em classes ou módulos separados, e seria uma má decisão de projeto de classes que elas estivessem juntas uma vez que mudam por diferentes motivos em momentos diferentes.

Você deve estar se perguntando "existe uma regra pra fazer essa separação?" e a resposta é não. O importante é que ao se projetar uma classe, analisar os momentos e os motivos que levariam você a alterar essa classe no futuro. Com um tempo essa tarefa vai ficar mais intuitiva e fácil de realizar