Balaio Tecnológico: Design Patterns com Delphi : Builder

7 de agosto de 2009

Design Patterns com Delphi : Builder - parte 1

O padrão de projeto Builder foi estabelecido para situações em que um objeto tem que ser construído em etapas ou passos de forma que esses passos podem ser abstraídos. Isto é, não importa os tipos reais (ou concretos) dos passos - sabe-se apenas que o objeto construído é composto por esses passos. Esse Design Pattern criacional difere do Abstract Factory no fato de que o Builder se propõe a criar objetos complexos passo a passo a partir de classes que não precisam estar relacionadas entre si, enquanto no Abstract Factory sempre é instanciada uma família correlata de classes. Na prática, é muito comum que uma situação seja mapeada como Abstract Factory no início de um projeto mas evolua para o Builder conforme a complexidade dos objetos construídos vai aumentando.

Exemplos de situações práticas nas quais utilizar este padrão incluem a geração do SPED Fiscal (Sistema Público de Escrituração Digital) e a criação do XML para a Nota Fiscal Eletrônica. No caso do SPED Fiscal, por exemplo, há uma série de documentos que devem ser criados para construir o pacote exigido pela Receita Federal. Alguns desses documentos variam de acordo com o ramo de atividade e com o Estado do Emissor, entre outros fatores. Os passos seriam a criação de cada um dos documentos isolados e o objeto final construido representaria o pacote a ser entregue à Receita. O mesmo vale para o XML da Nota Fiscal Eletrônica.

Conforme descrito no livro Design Patterns (que originou o conceito atual de Padrões aplicados à engenharia de Software), o padrão Builder é composto de 4 tipos de classes. O diagrama UML abaixo, que está publicado no Wikipedia, mostra estas classes e suas relações:

A classe Builder representada no diagrama acima é apenas uma interface abstrata, isto é, ela introduz uma forma padrão para se criar cada um dos passos necessários para a construção do objeto final. Essa interface tem necessariamente que ser implementada por uma ou mais classes do tipo ConcreteBuilder, que são as responsáveis por criar instâncias de passos isolados.

No caso do SPED, os passos da classe Builder devem incluir um método para construir os registros padronizados - aqueles que têm que existir, independendo de quaisquer características da empresa Emissora - e outro método para criar os registros extras, que dependem do ramo de atividade da empresa. Devemos, então, implementar classes ConcreteBuilder diferentes para representar cada ramo de atividade possível, com cada uma criando apenas os registros extras necessários para o próprio Ramo envolvido. Por exemplo, uma ConcreteBuilder para os registros exclusivos para a indústria de medicamentos, outra para a de armamentos, etc.

A classe Director do diagrama é responsável por juntar as partes, ou seja, é ela quem constrói o objeto final, chamando na ordem correta as funções que controem cada passo separado. O Director recebe como parâmetro a instância de um ConcreteBuilder e usa esta instância para gerenciar a criação dos passos. Pela forma como opera, é comum que o padrão Builder esteja associado a outros padrões criacionais. Por exemplo, usar uma Abstract Factory para determinar qual a classe ConcreteBuilder que deve ser usada pelo Director ou Singleton para garantir que haja no máximo apenas uma instância de cada ConcreteBuilder.

A última classe é o Product, que como o nome diz, é o produto final construído pelo Director. No caso do SPED, seria uma classe contendo a lista de registros digitais com as informações que devem ser enviadas ao fisco.

Para não me estender muito, coloco em outro post um exemplo com esses conceitos mapeados como classes em Delphi.