O documento descreve o padrão de projeto Abstract Factory, que fornece uma interface para criação de objetos delegando instanciações para subclasses. Ele é aplicado em um cenário de serviços bancários de um caixa eletrônico, onde a fábrica abstrata cria produtos como extratos e saldos de forma diferente para cada banco concreto, mantendo a aplicação cliente independente de implementações específicas.
1. Pós-Graduação Engenharia de Software
Disciplina Projeto de Sistemas de Software
Padrão de Projeto: Entendendo Abstract Factory
Lígia de Almeida Avelar
Thiago Antonius Oliveira Souza
Salvador, 8 de junho de 2009
2. Trabalho da Disciplina Projeto Tópicos Especiais em Projeto
de Sistemas de Software
Padrão de Projeto: Entendendo Abstract Factory
Autores
Lígia de Almeida Avelar
Thiago Antonius Oliveira Souza
1. Introdução
Padrões de projetos são soluções pré-determinadas para problemas que
comumente se repetem e podem ser reutilizadas em diversos cenários a partir de
adaptações. Christopher Alexander foi o responsável pelo desenvolvimento deste
conceito para a arquitetura na década de 70, segundo ele:
"Um padrão descreve um problema que ocorre inúmeraspar vezes em
determinado contexto, e descreve ainda a solução para esse problema, de
modo que essa solução possa ser utilizada sistematicamente em distintas
situações." [Alexander apud Macoratti]
Conhecidos como a Gang of Four (Gangue dos quatro) Eric Gamma, Richard
Helm, Ralph Johnson e John Vlissides escreveram o livro Design Pattern:
Elements of Reusable Object-Oriented Software responsável por disseminar o uso
de Padrões na área de Tecnologia da Informação, neste livro foram descritos 23
padrões conhecidos como padrões Gof.
"Os padrões de projeto são descrições de objetos que se comunicam e
classes que são customizadas para resolver um problema genérico de
design em um contexto específico" [GoF apud Rocha]
Os padrões GoF são classificados de acordo com o escopo – aplicação em
classes ou objetos – e a finalidade – o propósito da solução.
De acordo com o escopo os padrões se classificam em:
• Padrões para classes – tratam o relacionamento entre classes e subclasses
(herança), são estáticos por serem fixados em tempo de compilação.
• Padrões para objetos – tratam do relacionamento entre objetos
(associação e composição), são dinâmicos, pois podem se alterar
em tempo de execução.
De acordo com a finalidade os padrões se classificam em padrões de:
• Criação – Diz respeito à criação do objeto. Estes padrões abstraem o
processo de instanciação dos objetos tornando o sistema independente da
forma com que eles são criados, compostos e representados. [Souza].
3. Escopo de Classe Factory Method
Abstract Factory, Builder, Prototype,
Escopo de Objeto
Singleton
• Estruturais – Tratam das associações entre classes (usam herança para
compor interfaces) e objetos (descrevem formas de compor objetos para
realizar novas funcionalidades). [Souza]
Escopo de Classe Adapter
Bridge, Composite, Decorator, Façade,
Escopo de Objeto
Flyweight, Proxy
• Comportamentais – Diz respeito à interação e divisão de responsabilidades
entre classes e objetos.
Escopo de Classe Interpreter, Template Method
Chain of Responsability, Command,
Escopo de Objeto Iterator, Mediator, Memento, Observer,
State, Strategy, Visitor
Dentre os principais benefícios obtidos pela utilização de padrões de projetos
destacam-se:
• Soluções testadas, aprovadas e documentadas previamente;
• Facilidade de manutenção no sistema;
• Flexibilidade no sistema para mudanças;
• Os padrões utilizam as melhores práticas de Orientação a Objetos;
• Utilização de um vocabulário comum para os envolvidos no projeto;
2. Tutorial
2.1 Abstract Factory
O Padrão Abstract Factory ou Fábrica Abstrata fornece uma interface para criação de
objetos que delega as instanciações para as subclasses. Utilizado em casos onde o
cliente cria diferentes objetos definidos em tempo de execução. A estrutura do
Abstract Factory está representada através do diagrama abaixo:
4. 2.2 Cenário
Para aplicar os conceitos de Padrão de Projeto foi escolhido o contexto de um serviço
bancário realizado pelo Caixa Eletrônico 24h. O Caixa 24h possui uma aplicação
responsável por fornecer serviços como saldo, extrato e transferência para usuários
de diferentes bancos. A partir da autenticação do usuário a aplicação identifica em
qual banco será realizada a ação requerida. A aplicação deve ser flexível o suficiente
para que novos bancos possam ser agregados ao Caixa 24h sem causar grandes
impactos. Além disso, a aplicação cliente não precisa saber quais bancos são
implementados, nem como seus produtos estão desenvolvidos.
2.3 Solução
A solução com o Abstract Factory foi desenhada de acordo com o diagrama a seguir:
5. Foi criada uma classe Banco que representa a nossa fábrica abstrata que se refere ao
Banco 24h. Nela temos quatro métodos, são eles:
• obterFabrica() – Método responsável por instanciar as fábricas concretas,
como por exemplo, o Banco Real e o Banco do Brasil;
• criarExtrato() e criarSaldo() – Métodos abstratos, que definem os tipos de
produtos que cada fábrica concreta deve obrigatoriamente implementar.
• autentica() – Método abstrato responsável por autenticar o cliente, o mesmo foi
colocado na classe abstrata para que cada banco concreto faça a autenticação
de acordo com suas regras.
A fábrica abstrata Banco foi implementada da seguinte forma:
6. As fábricas concretas são responsáveis por implementar os métodos abstratos
criaSaldo() e criaExtrato(), para isso ela deve herdar a classe Banco. Como exemplo
de uma das fábricas concretas temos o código da classe BancoBrasil:
Para cada tipo de produto a ser criado deve se definir uma interface com os métodos
que necessitam ser implementados. No nosso contexto definimos as interfaces
Extrato e Saldo conforme código abaixo.
Foram criados produtos simples para facilitar a compreensão, porém os produtos
poderiam ter mais funcionalidades como, por exemplo, no caso do Extrato, gerar
extrato simplificado, completo, por período, dentre outros. Poderiam também ser
criados diversos produtos como saque, transferência, etc.
7. Deve existir uma implementação de cada produto para cada banco, abaixo
mostraremos os extratos do banco Real e Brasil:
Como pode ser visto em seguida cada banco tem a sua forma de gerar o extrato,
porém todos seguem a especificações da interface.
8. A aplicação cliente mostra como utilizar o padrão Abstract Factory. Como pode ser
visto no código abaixo, em nenhum momento a aplicação cliente se preocupa em
instanciar uma fábrica de determinado banco, ela simplesmente pede para a fábrica
abstrata Banco e esta se responsabiliza pela instanciação, tirando da aplicação todo
conhecimento de qual fábrica está sendo utilizada.
A fábrica abstrata cria a instância de uma fábrica concreta em tempo de execução a
partir de uma chave, esta chave é informada pelo usuário do banco, porém a solução
9. ideal seria a identificação do banco e os dados do usuário através do cartão do
banco.
É isso aí, o padrão Abstract Factory trouxe vários benefícios ao nosso sistema, com
ele ficou possível adicionar novos bancos ao Caixa 24h sem precisar modificar a
aplicação cliente, o padrão também centralizou a criação das fábricas de produtos,
logo caso precise modificar a forma de criação, só é necessário alterar em um único
lugar.
3. Bibliografia
MACORATTI, J.C. Padrões de Projeto – Design Patterns. Disponível na Internet.
http://www.macoratti.net/vb_pd1.htm. 01 de jun 2009.
ROCHA, H. da. Padrões de Projeto. Disponível na Internet.
http://www.argonavis.com.br/cursos/java/j930/J930_01.pdf. 01 de jun 2009.
SOUZA, V. E. S. Padrões de Projeto. Disponível na Internet.
http://www.disi.unitn.it/~vitorsouza/sites/default/files/DesignPatterns02.pdf. 01 de jun
2009