Esse artigo faz parte da revista Java Magazine edição 50. Clique aqui para ler todos os artigos desta edição

NT-SIZE: 10pt; COLOR: windowtext; FONT-FAMILY: Verdana">que aqui para ler esse artigo em PDF.imagem_pdf.jpg 

 Abstract Factory Aplicado

Use um importante pattern na criação de famílias de objetos

 

Neste artigo, vamos apresentar o design pattern (padrão de projeto) Abstract Factory, que é utilizado para a criação de um conjunto de objetos relacionados, os quais chamaremos de “família de objetos”. Também construímos um exemplo prático de seu uso, conjuntamente com o popular pattern Data Access Object (DAO).

 

Introdução

O pattern Abstract Factory foi apresentado pela primeira vez em 1995, na primeira edição do livro conhecido como “Padrões de Projeto” (Design Patterns). Considerado um marco na história do desenvolvimento de software, este livro foi escrito por quatro autores, que depois foram apelidados de “gangue dos quatro” (GoF, de Gang of Four). É utilizado como referência por diversos outros livros e sites dedicados a patterns. Nele são apresentados 23 patterns, classificados em patterns de criação, estruturais e comportamentais. O Abstract Factory é um pattern de criação. Para conhecer um pouco mais sobre patterns, consulte o “Design patterns e o DAO”.

 

Detalhando o Abstract Factory

A estrutura de tópicos utilizada para apresentação do Abstract Factory neste artigo é uma adaptação daquela seguida no livro do GoF:

Problema – Descrição do problema que se procura solucionar com o pattern.

Solução – Breve descrição da estratégia da solução a ser adotada.

Estrutura – Diagrama de classes mostrando os elementos utilizados na solução.

Participantes – Descrição de cada um dos elementos apresentados no diagrama criado no tópico Estrutura.

Colaborações – Diagrama de seqüência apresentando a interação entre os elementos utilizados.

Conseqüências – Resultados obtidos com a aplicação do pattern.

 

Problema

Precisamos criar famílias de objetos. Estas famílias são formadas por diversos objetos que podem possuir implementações diferentes. Devemos garantir que o aplicativo  utilize a família correta, não misturandoobjetos de famílias diferentes.

Por exemplo, uma família de objetos  pode ser o conjunto de DAOs utilizadospor um aplicativo. (Para o leitor não familiarizado com o pattern DAO, o quadro “Design patterns e o DAO” mostra alguns conceitos essenciais.) Podemos ter um conjunto de DAOs implementado para acesso ao banco de dados utilizando JDBC puro e outro implementado o acesso utilizando Hibernate. Podemos ainda ter um conjunto de DAOs utilizando JDBC com consultas SQL otimizadas para o banco de dados Oracle e outro para o MySQL, e outro ainda para o SQLServer – e assim por diante.

A situação que queremos evitar é que parte do aplicativo utilize DAOs de uma família enquanto outra parte utiliza DAOs de outra família. Imagine a situação de um aplicativo de gerenciamento de estoque que deve suportar os bancos de dados Oracle e SQLServer. Suponha que as classes DAO para produtos sejam empresa.oracle.ProdutoDAO e empresa.sqlserver.ProdutoDAO. Não queremos a situação onde a tela de edição utiliza um ProdutoDAO para banco de dados Oracle, enquanto a tela de listagem utiliza um ProdutoDAO para SQLServer, por um descuido do desenvolvedor. Esta situação poderia ocorrer facilmente se tivéssemos o seguinte código:

 

ProdutoDAO dao = new ProdutoDAO();

 

Neste exemplo simples, dependendo da classe que foi importada, o código pode tanto utilizar a classe para Oracle quanto a classe para SQLServer.

 

Solução

A solução é centralizar a criação dos objetos em uma classe que funciona como fábrica de objetos, de forma que possa haver diversas implementações diferentes dessas fábricas. Para isto devemos fornecer uma interface que define os métodos responsáveis pela criação dos objetos relacionados. Esta classe deve ser implementada pelas classes de fábricas concretas. ...

Quer ler esse conteúdo completo? Tenha acesso completo