Hoje falaremos sobre o SOLID que compreende cinco princípios da programação orientada a objetos que tem o objetivo de facilitar o desenvolvimento de software. Isto é, tornando mais fácil a manutenção e o entendimento do código.

Trataremos aqui do princípio da responsabilidade única – Single Responsability Principle, que por coincidência é o primeiro princípio do acrônimo SOLID O SRP é um dos mais importantes princípios programação orientada a objetos, visto que serve de base para outros princípios.

A título de conhecimento os demais princípios são, Open-Closed Principle (princípio aberto-fechado); Liskov Substitution Principle (princípio da substituição de Liskov); Interface Segregation Principle (Princípio da Segregação da Interface) e Dependency Inversion Principle (princípio da inversão da dependência) – S.O.L.I.D.

SRP – PRINCÍPIO DA RESPONSABILIDADE ÚNICA

O SRP – Single Responsibility Principle ou princípio da responsabilidade única diz que uma classe deve ser especializada em único assunto, e assim ter um e somente um motivo para mudar. Ou ainda, apenas uma tarefa ou ação para executar. Entretanto, tal princípio não é exclusividade das classes, ele pode ser aplicado inclusive aos métodos e funções.

Quanto mais de uma responsabilidade é atribuída a uma mesma classe, o que em um primeiro momento pode parecer o certo a se fazer, representará em um futuro não muito distante, um código difícil de ser mantido. Porque será um trabalho hercúleo modificar algumas dessas responsabilidades sem comprometer outras. Ou seja, serão grandiosas as chances de que seu código venha a se quebrar em algum momento.

PROBLEMAS DE VIOLAÇÃO DO SRP

A violação ao primeiro princípio SOLID – princípio de responsabilidade única pode gerar mais do que apenas alguns inconvenientes. Pode sinceramente implicar em uma grande dor de cabeça tanto para o desenvolvedor como para a equipe. Lembre-se que o princípio da responsabilidade única diz que uma classe deve ter um, e somente um motivo para mudar.

São exemplos de problemas que podem ocorrer quando um sistema desenvolvido sem que o programador leve este princípio em consideração.

  • FALTA DE COESÃO: A falta de coesão se estabelece quando uma classe assume responsabilidades que não são suas, ou não deveriam ser.
  • ALTO ACOPLAMENTO: Mais responsabilidades implica um nível realmente maior de dependências, como resultado tem-se um código engessado, sujeito a “quebrar”. Em síntese, tem-se um código que não suporta muito bem alterações de quaisquer naturezas.
  • AUSÊNCIA DE TESTES AUTOMATIZADOS: Torna-se difícil a simulação de comportamento de objetos reais de forma controlada.
  • COMPROMENTIMENTO DE REAPROVEITAMENTO DE CÓDIGO: Em um código engessado, com um alto nível de dependência é quase impossível o reaproveitamento de códigos.

ENTENDENDO SRP NA PRÁTICA

Dentro do Java podemos ter métodos internos do próprio objeto e métodos externos. A implementação de um método externo se dá quando o método irá receber uma informação externa. Neste caso, o ideal é que tudo o que a gente precise esteja dentro deste objeto. Não havendo desse modo, necessidade de recorrer a um método que esteja fora dele, em outra classe que não o referencie diretamente.

Veja como podemos trabalhar o primeiro princípio SOLID em um exemplo de conta bancária. Nesta classe implementaremos um método que terá a função única de somar e outro igualmente com a única função de subtrair valores de um saldo de 7500 (sete mil e quinhentos reais). 

public class contaBancaria{
     private String descricao;
     private double saldo = 7500;
}

Assim, podemos implementar, por exemplo, um método que soma cem reais ao saldo. E dessa forma, em qualquer lugar do programa só precisaremos chamar o método soma100 ou subtrai150. Ou podemos ainda receber do usuário o valor de saque ou depósito, do mesmo modo implementaremos todos estes métodos dentro da classe contaBancaria.

public void soma100(){
     saldo += 100;
}
public void subtrai150(){
     saldo -= 150;
}
public void sacarDinheiro(double saque){
     saldo -= saque;
}
public void depositarDinheiro(double deposito){
     saldo += deposito;
}

E por fim implementamos os métodos getters and setters e toString(). No método principal instaciaremos o objeto para podermos manipular o saldo da conta.

contaBancaria bancaria = new contaBancaria(); bancaria.setDescricao(“CONTA CORRENTE | ALEX”);

Ao manda mostrar na tela o resultado da implementação obteremos o seguinte resultado.

E se chamarmos duas vezes o método subtrai150(), e mandarmos imprimir na tela? O resultado será o valor do saldo inicial subtraído de trezentos reais.

E se um saque de quatrocentos e cinquenta reais for efetuado na conta chamando o método sacarDinheiro()? o resultado será.

Ou se decidirmos por um depósito de cento e setenta e cinco reais chamando o método depositarDinheiro().

EM POUCAS PALAVRAS

Qual seria, no caso do nosso exemplo a necessidade de criar um método externo em outro objeto para passar o contaBancaria, executá-lo e retornar o resultado? Nenhuma. Tudo o que o método precisa está no escopo da própria classe.

O fato é que aplicando o primeiro princípio do SOLID, o princípio da responsabilidade única, você estará certamente escrevendo códigos mais limpos, objetivos e de fácil manutenção e entendimento. Com a simples implementação do objeto bancaria instancia da classe contaBancaria, conseguimos acessar tudo o que nos importava referente as informações da conta. Ou seja, utilizando apenas o princípio da responsabilidade única, conseguimos bons resultados e um código limpo r fácil de entender.

E se precisarmos gerar um relatório, o mesmo não poderia ser responsabilidade da classe contaBancaria, visto que ela só manipula dados da conta. Se implementássemos uma rotina de emissão de relatórios na classe em questão estaríamos incorrendo em um erro de falta de coerência. Uma vez que não cabe a ela a responsabilidade de imprimir relatórios.