Artigos Delphi Boas práticas para redução de acoplamento no Delphi
Artigo do tipo Tutorial
Recursos especiais neste artigo:
Conteúdo sobre boas práticas
Porque esse artigo é útil
Ao desenvolver um software, não temos de início todas as funcionalidades que o mesmo deverá executar. Por mais que a fase de análise seja detalhada para levantar todos os requisitos, uma única coisa é certa. Esses irão mudar. Construir um aplicativo pensando em todas essas possíveis mudanças fica fácil quando se pensa na arquitetura a utilizar. Nesse artigo três boas práticas são abordadas, o uso de interfaces para isolamento das regras de negócio sujeitas a mudanças, injeção de dependência que reduz o quanto uma classe irá conhecer de outra e a aplicação de um container de inversão de controle, que flexibiliza o uso das interfaces como serviços de um software. Aplicando inicialmente essas três recomendações, qualquer sistema legado dá um passo para se tornar melhor, mais fácil de ser modificado.

Quando desenvolvemos um sistema, seja ele orientado a objetos ou não, o que mais queremos é que o mesmo seja fácil de manter. Esse é o pensamento inicial de cada projeto. Porém, com o passar do tempo, redução de prazos e custos, deixamos muitas vezes de pensar na arquitetura que irá permitir essa redução de trabalho de manutenção no futuro e nos preocupamos apenas no “entregar software”. O não pensar na arquitetura geral produz rotinas altamente acopladas, ou seja, rotinas que dependem, conhecem, tanto uma a outra que qualquer alteração em uma, implica em uma cascata de ajustes. Isso é acoplamento.

Existe uma boa prática comum no desenvolvimento orientado a objetos que permite reduzir essa forte dependência, mesmo que já exista um sistema legado é possível através de refactoring (BOX 1) ir melhorando partes críticas. Essa boa prática consiste em encapsular o que varia através de interfaces. Para clarificar esse processo vamos abordar um exemplo fictício, que mostrará partes de um pseudocódigo empregado para a solução do problema apresentado.

BOX 1. Refactoring

Um dos grandes problemas encontrados em sistemas de software é evitar a deterioração tão comum dos programas durante o ciclo de vida do sistema. Essa deterioração é, geralmente, causada por modificações com objetivos de curto prazo ou por alterações realizadas sem a clara compreensão da concepção do sistema. A refatoração (do inglês Refactoring) é o processo de modificação de software para melhorar o entendimento do código sem alterar suas funcionalidades, removendo duplicidades, melhorando a comunicação da equipe, simplificando e flexibilizando rotinas, facilitando a manutenção e evitando a inclusão de novos defeitos, aumentando assim a qualidade do produto.

O livro mais importante sobre o assunto é Refatoração - Aperfeiçoando o Projeto de Código Existente de Martin Fowler, que apresenta um catálogo com 72 refatorações, explicando seus conceitos e motivações, além de descrever detalhadamente cada uma das refatorações apresentadas.

O autor argumenta que, com treinamento apropriado, um profissional de computação pode transformar um projeto de baixa qualidade num código robusto e bem projetado, sem modificar seu comportamento observável. Outro bom argumento para a utilização dessa técnica é que qualquer um pode escrever código que um computador consiga entender, enquanto bons programadores escrevem código que pessoas conseguem entender.

A refatoração modifica um programa em pequenos passos. Assim, se um erro é cometido, torna-se mais fácil consertá-lo. Algumas oportunidades são apropriadas para aplicar refatoração. Deve-se refatorar quando for necessário construir código parecido com outro já existente, quando acrescentar novas funções, quando necessita consertar uma falha ou enquanto se revisa um código.

Utilizando interfaces

Pensemos em um exemplo bem simples, temos um site onde os clientes realizam pedidos e ao final é emitida uma cobrança. Vamos imaginar que em um primeiro momento os pagamentos serão realizados exclusivamente através de Boletos Bancários. Começamos então criando uma classe que será responsável por esse tipo de pagamento, veja na Listagem 1.

Listagem 1. Classe TBoleto


  TBoleto = class
  public
    procedure Cobrar(Valor: Currency);
  end;
  procedure TBoleto.Cobrar(Valor: Currency);
  begin
    Writeln('Emit ...

Quer ler esse conteúdo completo? Tenha acesso completo