Fala ai Radizeiros e Radizeiras, tudo bem com vocês?
A cada atualização é uma dor de cabeça, você altera algo em seu software e acaba tendo um trabalho tremendo tendo que ajustar em outras partes do seu software.
Este problema é algo que acontece com frequência quando temos códigos acoplados e que não seguem o Princípio da Responsabilidade Única.
Neste post irei falar sobre o Princípio da Responsabilidade Única, que nada mais é que uns dos princípios do SOLID, o conceito deste principio é que cada classe e cada método tem que resolver aquilo que lhe foi proposto a ser resolvido, cada método tem apenas uma responsabilidade, outra coisa que devemos colocar é que cada classe tem apenas uma única razão para mudar.
Mas como é isso?
Vamos dizer que você tem uma classe de CLIENTE e fez uma alteração no FINANCEIRO, se você seguiu todos os princípios do SOLID, essa alteração na regra de negocio do FINANCEIRO não irá interferir em nada em nossa classe de CLIENTE, porque foi uma coisa especifica do FINANCEIRO.
Quando você acopla as duas classes ai você tem um problema, pois ao fazer uma alteração no FINANCEIRO você terá que alterar também na classe de CLIENTE, e ai essa classe de CLIENTE tem relação com outras classes, você vai terá uma cadeia de reações por causa desse tipo de alteração.
Seguindo o Princípio da Responsabilidade Única, tendo seu código desacoplado, terá uma manutenção muito mais sadia, e que alterações antes eram complexas em seu software passam ser coisas triviais que você irá tirar de letra.
Quais são os problemas que podemos ter se não seguirmos esses princípios?
Você já deve ter reparado que quando não seguimos o Principio da Responsabilidade Única o nosso código não é coeso, falo sobre coesão em um dos meus treinamentos o de Certificação especialista em Clean Code e Boas práticas de programação, e é muito importante que venhamos manter nosso código coeso.
Quando não seguimos esses princípios iremos ter logo de cara a dificuldade tanto na compreensão quanto do funcionamento dos métodos, ou seja, mandei chamar um método qualquer, por exemplo emitir uma nota fiscal, se dentro desse método eu tenho acoplado funções para gerar PDF, enviar XML por e-mail e tudo mais, isso já causa uma dificuldade na compreensão na hora de você estar executando ou debugando esse projeto, você vai achar que ele está fazendo uma coisa, e na realizada ele está fazendo muito mais coisas.
Uma alteração em um método como esse pode prejudicar a manutenção do seu software, você pode está desencadeando erros em outros pontos do seu software.
Esse é o primeiro problema que você pode ter quando você não tem uma baixa coesão, e quando você não segue o principio da responsabilidade única.
Outra coisa que é bem clara quando não seguimos esses princípios, é a dificuldade do reuso.
Se eu tenho um método para emitir nota fiscal, que ela também manda e-mail, gera PDF, se algum momento o meu cliente não tem um e-mail ou não quer receber esse e-mail, eu vou ter que, não somente tratar isso no meu cliente como também terei que desencadear isso para dentro do método da nota fiscal, e não poderei reutilizar essa função de reenviar nota para todos os clientes, porque ai já vou ter que ter variáveis para saber se pode ou não pode, ai começo gerar um monte de sujeiras dentro do meu código sem necessidade, onde eu poderia ter evitado se tivesse separado cada método resolvendo aquilo que ele se propõe a resolver.
Por último, o que temos de evidente é o alto acoplamento, se eu preciso numa classe de nota fiscal eletrônica gerar PDF, enviar e-mail, eu provavelmente estou acoplando a minha classe de e-mail e minha classe de PDF dentro da minha classe de nota fiscal, algo que eu não deveria fazer, o que deveria era ter uma camada para tratar isso, e minha classe de nota fiscal só resolver a nota fiscal, você não seguindo esse principio você vai ter um alto acoplamento dentro do seu código, o que não é legal.
Agora da uma olha nesse método de exemplo.
procedure TForm1.Venda;
begin
AdicionarProduto(StrToInt(Edit1.Text));
CalcularTotal;
EnviarEmail;
end;
Podemos observar que é um método simples de venda, onde ele claramente está violando o principio da responsabilidade unica, porque ele está adicionando produto e logo em seguida está calculando o total.
Provavelmente esse nossos dois primeiros métodos pertencem a classe de venda, mas logo depois ele está enviando um e-mail para o meu cliente baseado na minha classe de venda, já estamos violando o Princípio da Responsabilidade Única, porque minha classe de venda era para tratar apenas com a venda.
Deveríamos tratar todos esses problemas de uma outra maneira onde em um dos meus treinamentos Certificação especialista em Clean Code e Boas práticas de programação falo de como iremos tratar utilizando padrões de projetos específicos para cada uma dessas responsabilidades.
Não é uma boa prática agente acoplar funções, criar listas de métodos que se entrelacem entre as classes, onde acaba violando outros princípios do SOLID.
Se você deseja melhorar os seus ganhos, se qualificar para estar acima da média e se tornar um especialista para receber ótimas propostas de grandes empresas do seu nicho, eu te convido a dar qualidade ao seu código com um treinamento incrível que irá transformar sua carreira de desenvolvedor Delphi.
A Certificação Especialista em Clean Code e Boas Práticas de Programação em Delphi.
CLIQUE AQUI PARA SABER MAIS SOBRE O TREINAMENTO CERTIFICAÇÃO ESPECIALISTA EM CLEAN CODE E BOAS PRÁTICAS DE PROGRAMAÇÃO EM DELPHI
