Padrão Abstract Factory Projeto de Sistemas de Software Hazel Carvalho Crato.

Padrão Abstract Factory

Projeto de Sistemas de Software

Hazel Carvalho Crato

© LES/PUC-Rio

Sumário

• Abstract Factory

– Propósito

– Motivação

– Aplicabilidade

– Estrutura

– Participantes

– Colaborações

– Conseqüências

– Exemplo de Código

© LES/PUC-Rio

Abstract Factory

• É classificado como um padrão de criação, também conhecido como Kit.

• Propósito

– Prover uma interface para criar famílias de objetos relacionados ou dependentes sem especificar suas classes concretas.

© LES/PUC-Rio

Motivação

Exemplo 1:

© LES/PUC-Rio

Motivação

Exemplo 2:

© LES/PUC-Rio

Motivação

• Diferentes padrões look-and-feel definem diferentes aparências (look) e comportamentos (feel) para um widget de uma interface de usuário. Exemplos: barras de rolagem, janelas, botões etc.

• Para ser portável através dos padrões look-and-feel, uma aplicação não deve instanciar os widgets diretamente de suas classes concretas para uma aparência ou comportamento particular.

• Para facilitar a alteração da aparência e do comportamento futuramente, defina uma classe abstrata GUIFactory que declara uma interface para criar cada tipo de widget básico.

• Defina ainda uma interface para cada tipo de widget e subclasses concretas que implementam widgets para um específico padrão look-and-feel.

© LES/PUC-Rio

Motivação

• A interface de GUIFactory possui uma operação que retorna um novo widget concreto para cada widget abstrato.

• Há uma sub-classe concreta de GUIFactory para cada padrão look-and-feel.

• Cada sub-classe implementa as operações para criar o widget apropriado para o respectivo look-and-feel.

• Clientes criam os widgets apenas através da GUIFactory sem saber quem são widgets concretos para um específico look-and-feel.

• Uma GUIFactory reforça as dependências entre as classes concretas de widgets.

© LES/PUC-Rio

Aplicabilidade

• O padrão deve ser usado quando:

– Um sistema deve ser implementado independente de como os produtos são criados, compostos e representados.

– Um sistema deve ser configurado com uma das múltiplas famílias de produtos.

– Uma familia de um produto relacionado é projetada para ser utilizada junta, e faz-se necessário o reforço dessa restriçao.

– Deseja-se prover uma biblioteca de classes de produtos e deseja-se revelar apenas as suas interfaces, mas não suas implementações.

© LES/PUC-Rio

Estrutura

© LES/PUC-Rio

Participantes

• AbstractFactory – Declara uma interface para operações que criam produtos

abstratos.

• ConcreteFactory – Implementa as operações para criar produtos concretos.

• AbstractProduct – Declara uma interface para um tipo de produto.

• ConcreteProduct – Define um produto a ser criado pela fábrica concreta

correspondente.

– Implementa a interface AbstractProduct.

• Client – Usa apenas interfaces declaradas pelas classes AbstractFactory

e AbstractProduct.

© LES/PUC-Rio

Colaborações

• Normalmente uma única instância da classe ConcreteFactory é criada em tempo de execução.

• AbstractFactory delega a criação de produtos concretos para a respectiva subclasse ConcreteFactory.

• A classe ConcreteFactory cria produtos que possuem uma implementação particular, por exemplo: todos os widgets de uma WinFactory concreta.

© LES/PUC-Rio

Conseqüências

• Vantagens

– Abstract Factory isola classes concretas.

– Facilita o intercâmbio de famílias de produtos.

– Promove consistência entre produtos.

• Desvantagem

– Suporte a novos tipos de produtos é dicífil.

Exemplo de Código

© LES/PUC-Rio

Estrutura

Perguntas?

Padrão Abstract Factory Projeto de Sistemas de Software Hazel Carvalho Crato.

Documents

Transcript of Padrão Abstract Factory Projeto de Sistemas de Software Hazel Carvalho Crato.