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
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].
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:
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:
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:
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.
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.
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
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

Travalho versao final

  • 1.
    Pós-Graduação Engenharia deSoftware 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 DisciplinaProjeto 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 aplicaros 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 umaclasse 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 concretassã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 umaimplementaçã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 clientemostra 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 aidentificaçã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