S → Single Reponsability Principle (Princípio Responsabilidade Única)

O SRP é o mais abstrato do conjunto da sigla SOLID, além de ser considerado o mais simples de compreender. Este conceito ajuda a definir classes e métodos pequenos que são fáceis de manter.

“Uma classe deve ter apenas uma única responsabilidade, ou seja, apenas alterações em uma parte da especificação do software devem ser capazes de afetar a especificação da classe.”(Uncle Bob)

Embora todos concordamos que o foco em uma única responsabilidade é importante. é difícil determinar qual é a responsabilidade de uma classe. Geralmente diz-se que qualquer coisa que dê a uma classe uma razão para mudar pode ser vista como uma responsabilidade. Por mudança, estou falando de mudanças estruturais na própria classe (como na modificação do código no arquivo de classe, não no estado na memória do objeto). Vejamos um exemplo de um código que não esta seguindo o princípio:

public class Deal{
   private BigDecimal amount;
   private boolean processed;
	//getters
  //setters
  public void save(){
		//....
  }
}

public class DealProcessor {
	List<Deal> deals;
  public DealProcessor(List<BigDecimal> deals){
		this.deals = deals;
	}

  public void process(){
		this.deals.forEach(deal -> {
			Commission.create(deal, calculateCommission(deal));
			markDealProcessed(deal);
		});
	}

	private void markDealProcessed(Deal deal) {
		deal.setProcessed(true);
    deal.save();
	}

  private void calculateCommission(Deal deal){
		deal.amount.multiple(0.05);
	}

}

Na classe acima (DealProcessor), temos uma unica interface de comando que processa pagamento de comissões para negócios. À primeira vista, a classe parece bastante simples, mas vamos ver o motivos pelos quais podemos querer mudar essa classe. Qualquer alteração na forma como calculamos as comissões exigiria uma alteração nessa classe. Poderíamos introduzir novas regras de comissão ou estratégias que fariam com que nosso método calculateCommission() mudasse. Por exemplo, podemos querer varias porcentagem com base no valor do negócio. Qualquer alteração nessas etapas seria necessárias para marcar um negócio como processado no método markDealProcessed(...) resultaria uma alteração no arquivo também. Um exemplo disso pode ser adicionar suporte para enviar um resumo por e-mail das comissões de uma pessoa especifica, após marcar o negócio como processado. O fato de podermos identificar vários motivos para mudar sinaliza uma violação do Princípio de Responsabilidade Única.

Podemos fazer uma refatoração rápida e obter nosso código em conformidade com o Princípio da Responsabilidade Única.

public class Deal{
   private BigDecimal amount;
   private boolean processed;
	//getters
  //setters
  public void save(){
		//....
  }
}

public class DealProcessor {
	List<Deal> deals;
  public DealProcessor(List<BigDecimal> deals){
		this.deals = deals;
	}

  public void process(){
		this.deals.forEach(deal -> {
			markDealProcessed(deal);
			CommissionCalculator.createCommission(deal);
			
		});
	}

	private void markDealProcessed(Deal deal) {
		deal.setProcessed(true);
    deal.save();
	}
}

class CommissionCalculator {
	public static void createCommission(Deal deal){
			Commission.create(deal, deal.amount.multiple(0.05));
	}
}

Agora temos duas classes menores que lidam com as duas tarefas especificas. Temos nosso processador que é responsável pelo processamento e nossa calculadora que calcula o valor e cria todos os dados associados à nossa nova comissão.

Resumindo o beneficio de seguir o princípio SRP é que podemos alterar o comportamento de uma função editando uma única classe responsável pelo comportamento. Além disso, se uma única funcionalidade for interrompida, você saberá onde o bug estará no código e poderá confiar que apenas essa classe será interrompida.

Vamos falar no próximo artigo sobre OCP (Open/Close Principle) .