Acoplamento temporário explícito

Saudações, leitores!
Acoplamento temporário explícitoBons desenvolvedores sabem que um método deve executar apenas uma tarefa, conforme o princípio de responsabilidade única (SRP). Porém, algumas vezes, na busca por manter os métodos objetivos e enxutos, escondemos o acoplamento temporário que existe entre eles, ofuscando a dependência lógica que um método tem com o outro.
Ainda não ouviu falar sobre acoplamento temporário? Acompanhe o artigo e tome conhecimento de como eles devem ser codificados!

 

Assim como aprendemos na disciplina básica de programação, um algoritmo é uma sequência de passos em um procedimento para que uma tarefa seja realizada. A palavra “sequência” é importante nesse contexto. Nós, desenvolvedores, compreendemos que os métodos devem ser chamados em uma sequência lógica para executar o que o usuário espera e, claro, para que também não ocorram erros. No entanto, além da sequência, uma boa prática é “revelar” a ligação que existe entre os métodos deste fluxo, justamente para evitar uma possível inconsistência nas chamadas. Bom, ao invés de tentar explicar só na teoria, creio que seja melhor apresentar um exemplo.
No código abaixo, um desenvolvedor codificou um método responsável por processar a impressão de um relatório:

procedure TClasseVenda.ProcessarImpressaoRelatorio;
begin
  ConsultarDadosCliente;
  DefinirTipoRelatorio;
  ImprimirRelatorio;
end;

 

O método é pequeno e o objetivo está claro. O processamento do relatório consiste na consulta dos dados do cliente, seguido da definição do tipo do relatório conforme o perfil e, por fim, na impressão desejada. Este é o acoplamento temporário que existe entre os três métodos, ou seja, apresentam uma dependência para que a operação funcione. Sendo assim, não é cabível, por exemplo, imprimir o relatório sem antes definir o seu tipo.
Agora, vamos supor que outro desenvolvedor irá utilizar este mesmo fluxo de chamadas em outro formulário da aplicação. Ao escrever o código, ele se confunde com a sequência de métodos e implementa da forma abaixo:

procedure TClasseVenda.ProcessarImpressaoRelatorio;
begin
  DefinirTipoRelatorio;
  ConsultarDadosCliente;
  ImprimirRelatorio;
end;

Opa, tem coisa estranha aí… as duas primeiras linhas estão invertidas! Quando o processamento do relatório for executado, ocorrerá um erro na aplicação ou o relatório será gerado com dados incorretos, já que o tipo está sendo definido antes da consulta de dados do cliente. Para falar a verdade, não culpo o desenvolvedor por ter errado a sequência. Lendo o código, fica relativamente claro compreender que é preciso definir o tipo, consultar os dados e imprimir o relatório.

 

Mas, então, como podemos evitar essa incoerência da sequência de métodos?
Simples. Basta fazer com que o acoplamento temporário seja explícito! A dependência entre os métodos deve ser visível. Para isso, podemos, por exemplo, utilizar parâmetros nos métodos. Observe como o código fica mais expressivo ao aplicarmos essa técnica:

procedure TClasseVenda.ProcessarImpressaoRelatorio(const CodigoCliente: integer);
var
  DadosCliente: TCliente;
  TipoRelatorio: TTipoRelatorio;
begin
  DadosCliente := ConsultarDadosCliente(CodigoCliente);
  TipoRelatorio := DefinirTipoRelatorio(DadosCliente.Perfil);
  ImprimirRelatorio(TipoRelatorio);
end;

 

Com a correção acima, é praticamente impossível implementar a chamada dos métodos fora de sequência. Temos essa garantia porque o fluxo passa a ser interpretado da seguinte forma: para imprimir o relatório, é necessário informar o tipo; para encontrar o tipo, é preciso informar o perfil do cliente; para buscar o perfil do cliente, deve-se consultar os dados; para consultar os dados, é solicitado o código do cliente. Legal, não é? 🙂

Leitores, embora pareça uma dica bem básica, é um detalhe que colabora bastante para a expressividade do código e que às vezes passa despercebido.

 

Até a próxima semana, pessoal!


 

Compartilhe!
Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Pin on PinterestEmail this to someone

2 comentários

  1. Muito bom André , meu código não é organizado que nem o seu as vezes eu esqueço o que eu já fiz
    e duplico ate variável global kkkk , você falou que isso é uma coisa bem básica , mas a base de qualquer coisa é o mais importante talvez se eu tive se uma boa base não cometeria esses erros básicos. Muito bom mesmo continue sempre assim.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Preencha o campo abaixo * Time limit is exhausted. Please reload CAPTCHA.