Artigo Java Magazine 78 - Builder e Composite: padrões para a sua caixa de ferramentas

O artigo aborda dois padrões de projeto, Builder e Composite, essenciais para a “caixa de ferramentas” de qualquer desenvolvedor de software, uma vez que é frequente a ocorrência de cenários nos quais a aplicação destes padrões é possível.

Java Magazine 78

[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]

> Clique aqui para ler todos os artigos da Java Magazine 78

Builder e Composite: padrões para a sua caixa de ferramentas
Boas práticas de desenho/projeto de software
Como construir diferentes representações de objetos passo-a-passo e trabalhar com estruturas hierárquicas

Em diferentes projetos de software, existem características, oportunidades e problemas semelhantes. Podem ser citados como exemplo: criação e gerenciamento de fontes de recursos, centralização do controle de requisições, portabilidade para diferentes Sistemas Gerenciadores de Bancos de Dados (SGBDs), entre outros.
Essa semelhança possibilita o reaproveitamento de estratégias e soluções, o que é importante frente ao cenário atual de desenvolvimento de software, no qual é necessário maior produtividade e melhor qualidade para ser competitivo.
Padrões de projeto desempenham um papel de destaque neste contexto, uma vez que podem ser entendidos como uma forma de reuso de soluções para problemas comuns de desenho/projeto de software.
Um padrão de projeto geralmente especifica um nome, a descrição de um problema/motivação para seu uso, uma solução para o problema apresentado e as consequências da sua aplicação.
Além de auxiliarem no aumento da produtividade, principalmente por permitirem o reuso de soluções, e no desenvolvimento de projetos com melhor qualidade, por meio do uso de soluções flexíveis, testadas e documentadas, os padrões de projeto definem um vocabulário comum para a discussão dos problemas para os quais propõem soluções .
Os padrões de projeto ganharam popularidade com o livro Design Patterns: elements of reusable object-oriented software , no qual foram catalogados vinte e três padrões, que foram classificados tanto de acordo com seu propósito (Tabela 1) quanto de acordo com sua intenção (Tabela 2).

Propósito   Padrões de Projeto
Criação   Factory Method, Abstract Factory, Builder, Prototype e Singleton.
Criação e inicialização de objetos.
Estrutura   Adapter, Bridge, Composite, Decorator, Facade, Flyweight e Proxy.
Composição de classes ou objetos.
Comportamento   Interpreter, Template Method, Chain of Responsibility, Command, Iterator,
Mediator, Memento, Observer, State, Strategy e Visitor.
Interação e distribuição de responsabilidades entre classes e objetos.
Tabela 1. Classificação dos 23 padrões de projeto proposta pelos autores do livro Design Patterns.

Intenção   Padrões de Projeto
Interfaces   Adapter, Bridge, Composite e Facade.
Oferecer interfaces.
Responsabilidade   Chain of Responsibility, Flyweight, Mediator, Observer, Proxy e Singleton.
Atribuir responsabilidades.
Construção   Abstract Factory, Builder, Factory Method, Memento e Prototype.
Construir classes ou objetos.
Operações   Command, Interpreter, State, Strategy e Template Method.
Controlar formas de operação.
Extensões   Decorator, Iterator e Visitor.
Implementar extensões.
Tabela 2. Classificação dos 23 padrões de projeto proposta por Steven John Metsker no livro Design Patterns in Java.
Além dos padrões descritos no livro Design Patterns, diversos outros foram catalogados e publicados, tais como: Patterns of Enterprise Application Architecture, Core J2EE Design Patterns: best practices and design strategies, entre outros.
Neste artigo, serão abordados dois padrões de projeto: Builder e Composite. O primeiro pode ser empregado com qualquer objeto para o qual seja necessário construir passo-a-passo diferentes representações – nestes casos, pode-se dizer que o processo de construção do objeto é complexo. Composite, por sua vez, pode ser empregado na organização e tratamento de estruturas hierárquicas.
Como ambos os padrões podem ser empregados com estruturas hierárquicas – já que a construção deste tipo de estrutura geralmente envolve processos complexos e o padrão Builder se aplica nesse caso –, inicialmente serão analisados alguns domínios nos quais tais estruturas aparecem.
"