Travalho versao final

942 visualizações

Publicada em

Publicada em: Educação
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
942
No SlideShare
0
A partir de incorporações
0
Número de incorporações
1
Ações
Compartilhamentos
0
Downloads
22
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Travalho versao final

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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

×