Começando pelo começo...
O que é um Padrão de Projeto?
Bom, vamos pela definição dos caras, os pais destes conceitos no ramo da Engenharia de Software. (Sério, estude sobre esses caras):
Erich Gama, Richard Helm, Ralph Johnson e John Vlissides
Segundo Christopher Alexander, “cada padrão descreve um problema no nosso ambiente e o núcleo da sua solução, de tal forma que você possa usar esta solução mais de um milhão de vezes, sem nunca faze-lo da mesma maneira”.
Resumidamente pode-se entender como padrão de projeto, como a solução recorrente para um problema em um contexto, mesmo que em projetos e áreas distintas. Observe que os termos chaves dessa definição são: contexto, problema e solução, o que torna obrigatório à compreensão inequívoca de cada um.
O que estes caras tem de tão importantes? O que eles fizeram?
Em 1995 Erich Gama, Richard Helm, Ralph Johnson, John Vlissides, conhecidos como os quatro amigos [Gang of Four - GoF], publicaram o livro sobre o título: “Design patterns – elements of reusable object-oriented software, Addison Wesley Longman”, que ganhou uma versão na língua portuguesa sobre o título de “Padrões de Projeto – Soluções reutilizáveis de software orientado a objetos. Bookman”. O livro é um catálogo que descreve 23 padrões de projeto cada um fornecendo uma solução para um problema de software, seu contexto, aplicação e suas eventuais conseqüências, dividindo-os em 3 categorias: padrões de criação, estruturais, e de comportamento.
Tá, mas e ai? E agora José?
E ai? E ai que o uso de padrões de projeto propicia a construção de aplicações e ou estruturas de código de forma flexível e a documentação de soluções reaproveitáveis. Através deles é possível identificar os pontos comuns entre duas soluções diferentes para um mesmo problema.
Conhecer esses pontos comuns nos permite desenvolver soluções cada vez melhores e mais eficientes que podem ser reutilizadas, permitindo, assim, o avanço do conhecimento humano.
Os padrões possibilitam através de uma linguagem clara e concisa, que os projetistas experientes transfiram os seus conhecimentos aos mais novos em um alto nível de abstração e assim facilitam o desenvolvimento e o reaproveitamento de código.
Vamos ao que interessa, o que é o tal "Abstract Factory"?
A intenção deste é fornecer uma interface para criação de famílias de objetos relacionados ou dependentes sem especificar suas classes concretas. Também é conhecido como Kit.
Este padrão deve ser aplicado quando se deseja isolar a aplicação da implementação da classe concreta, que poderia ser um componente e ou framework específico no qual a aplicação conheceria apenas uma interface e a implementação concreta seria conhecida apenas em tempo de execução ou compilação.
Imagine que em uma aplicação houvesse a necessidade de que ela fosse implementada para oferecer suporte a plataformas e características distintas. Por exemplo: Uma visão desktop e uma móvel (celular Pocket PC). A maneira de constituí-la, seria definindo uma família de componentes para cada plataforma e uma fábrica que os instancia de acordo com a plataforma alvo na qual a aplicação estará sendo executada.
De acordo com o exposto pelos quatro amigos, o uso do padrão Abstract Factory deve estar restrito as seguintes situações:
Um sistema deve ser independente de como seus produtos são criados, compostos ou representados;
Um sistema deve ser configurado como um produto de uma família de múltiplos produtos;
Uma família de objetos for projetada para ser usada em conjunto, e você necessita garantir esta restrição;
Você quer fornecer uma biblioteca de classes de produtos e quer revelar somente suas interfaces, não suas implementações.
A estrutura arquitetural do padrão definido segundo GoF é de acordo com o apresentado na Figura 1.
Figura 1. Estrutura arquitetural do padrão
A estrutura de um exemplo mais de acordo com a realidade do desenvolvedor é apresentada na Figura 2. A ideia básica apresentada pela figura é a de oferecer ao usuário (desenvolvedor) a possibilidade de executar uma aplicação sobre diferentes plataformas.
Figura 2. Diversas plataformas
Os participantes são:
ComponentFactory - declara uma interface para operações que criam objetos dos componentes utilizados na aplicação;
PocketFactory – classe concreta que implementa as operações que criam os objetos no formato do dispositivo cliente;
PCFactory - classe concreta que implementa as operações responsáveis por criar os objetos no formato do PC.
Mas nem tudo são flores....
O padrão Abstract Factory possui os seguintes benefícios e desvantagens:
- Ele isola as classes concretas.
- Ele torna fácil a troca de famílias de produtos.
- Ela promove a harmonia entre produtos.
- É difícil de suportar novos tipos de produtos.
Buenas... Era wilson!
Pesquise mais sobre o assunto Jovem!
Criado e Publicado para a disciplina de Engenharia de Software III, IFRS Porto Alegre
Referências
DevMedia : Conheça os Padrões de Perojeto
Design Patterns :Padrões de Projeto Soluções Reutilizáveis de Software Orientado a Objetos
Top comments (0)