Ensaios Noturnosensaios porque não passam de tentativas de bons posts... noturnos porquem as idéias geralmente chegam quando estou prestes a dormir...o que inclusive me irrita, pois sou obrigado, diversas vezes, a levantar e anotar para um futuro desenvolvimento da idéia

A segunda pattern explicada no livro Design Patterns é o builder. Ela é muito parecida com a pattern AbstractFactory explicada no post anterior, mas ela possui um foco diferente.

O intuito desta pattern é separar o processo de criação de um objeto da sua representação. Assim, um objeto complexo, que exigiria algumas etapas para sua construção, pode ter um builder genérico que serviria para diferentes representações desse objeto.

O exemplo utilizado no livro é de um leitor de formato RTF. Esse leitor pode criar uma outra representação do formato RTF de várias maneiras: em puro texto, em formatação alternativas como o LeX, ou até em representações gráficas. Cada uma dessas representações é um produto distinto, mas, em todas elas, o processo de conversão a partir do RTF analisaria o texto sequencialmente, e executaria processos especiais para coisas como: mudança de fonte, mudança de parágrafo, inserção de caracteres especiais e etc.

O diagrama de classes abaixo ilustra como é a solução oferecida por esta pattern.

Na ilustração não está o papel do cliente. O interesse do cliente é obter um Produto. Para isso ele precisará ter conhecimento do Diretor (genérico) e do Builder, mas reparem que o Cliente precisa conhecer o builder concreto e não apenas o abstrato. Isso porque o método GetResult não está declarado na interface Builder.

Esta pattern, portanto, torna o seu sistema dependente do produto final. O que a pattern vai abstrair é o processo de criação do produto, guiado pela implementação do método Construct pelo Diretor (que vai construindo as partes do produto, sem precisar conhecer sequer qual é a interface do produto).

É decisivo nesta pattern a escolha de um processo de criação do produto com uma granularidade fina o suficiente para a criação das diferentes representações do Produto. Isso pode ser um problema para alguns dos builders concretos mais simples, que necessitem implementar várias partes vazias desse processo. Um jeito interessante de se fazer o Builder para evitar isso é através de métodos BuildPart vazios, para que os builders concretos implementem apenas os processos que lhe são interessantes.

Eu confesso nunca vi esta pattern em ação, mas fazendo uma comparação com a AbstractFactory vejo duas diferentes:

1. O builder está focado na construção do objeto na forma de passos (partes)
2. O cliente fica dependente da classe concreta do builder (não é um defeito, a pattern foi feita propositadamente desta forma, a intenção era permitir diferentes conjuntos de construção e representação para um produto conhecido)