A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Design Patterns Elisabeth Suescún Leandra Mara da Silva.

Apresentações semelhantes


Apresentação em tema: "Design Patterns Elisabeth Suescún Leandra Mara da Silva."— Transcrição da apresentação:

1 Design Patterns Elisabeth Suescún Leandra Mara da Silva

2 © LES/PUC-Rio Motivação –Aprimorar conhecimentos de Projeto de Sistemas de Software, realizando um estudo sobre os Padrões de Projeto apresentados em [GoF]. Objetivo –Fornecer uma visão geral sobre o padrão Bridge.

3 Padrão Bridge (Handle/Body)

4 © LES/PUC-Rio Bridge Classificação –Estrutural de Objeto Propósito –Desacoplar uma abstração de sua implementação para que ambos possam variar independentemente

5 © LES/PUC-Rio Bridge Motivação (O Problema) –Imagine um sistema gráfico de janelas que deve ser portável para diversas plataformas. –Normalmente, a portabilidade seria obtida criando-se especializações dos tipos de janelas para cada uma das plataformas suportadas.

6 © LES/PUC-Rio Bridge Motivação (continuação) –Observa-se pelo diagrama anterior que: Para cada tipo de janela, devem ser definidas tantas classes quanto forem o nº de plataformas –O que acontece com a adição de uma nova plataforma? –E de outro tipo de janela? –E se forem vários os tipos de janelas e plataformas? Resultado: Proliferação de classes

7 © LES/PUC-Rio Bridge Motivação (A Solução) Exemplo de solução: –O padrão Bridge permite colocar as abstrações e suas implementações em diferentes hierarquias de classes, e permite que variem de forma independente –São criadas duas hierarquias de classes relacionadas: a hierarquia de tipos de janelas e a de implementação nas plataformas suportadas. O relacionamento entre as interfaces é a ponte que desacopla a interface da implementação –O diagrama do próximo slide mostra a solução citada

8 © LES/PUC-Rio Bridge Motivação

9 © LES/PUC-Rio Bridge Aplicabilidade (use o padrão quando:) –Desejar evitar ligação permanente entre uma abstração e sua implementação. Pode ser, por exemplo, quando se deseja variar a implementação em tempo de execução (runtime) –Tanto a abstração quanto a implementação devem ser extensíveis através de herança –Mudanças na implementação de uma abstração não devem ter impacto sobre o cliente –Você tem uma proliferação de classes, e quer evitá-las dividindo o objeto em duas partes –Você quer compartilhar uma implementação entre múltiplos objetos e este fato deve ser escondido do cliente.

10 © LES/PUC-Rio Bridge Estrutura

11 © LES/PUC-Rio Bridge Participantes –Abstraction (Window) Define a interface da abstração Mantém uma referência para um objeto do tipo Implementor –RefinedAbstraction (IconWindow) Estende a interface definida por Abstraction –Implementor (WindowImp) Define a interface para as classes de implementação Não precisa corresponder exatamente à interface de Abstraction –ConcreteImplementor (XwindowImp, PMWindowImp) Implementa a interface de Implementor e define sua implementação concreta

12 © LES/PUC-Rio Bridge Colaborações –Abstraction repassa as solicitações dos clientes para o seu objeto Implementor

13 © LES/PUC-Rio Bridge Conseqüências –Implementação de abstração pode ser configurada em tempo de execução –Mudanças de uma implementação não torna necessário a recompilação da classe Abstraction e seus clientes. –Melhorias na estrutura do sistema, encorajando o uso o de camadas; a parte de alto nível somente tem que ter conhecimento de Abstraction e Implementor –Extensibilidade melhorada: pode-se estender as hierarquias de Abstraction e Implementor independentemente –Ocultação de detalhes de implementação dos clientes

14 © LES/PUC-Rio Bridge

15 © LES/PUC-Rio

16 Bridge

17 © LES/PUC-Rio

18 Bridge © LES/PUC-Rio

19 Bridge © LES/PUC-Rio

20 Fim!!


Carregar ppt "Design Patterns Elisabeth Suescún Leandra Mara da Silva."

Apresentações semelhantes


Anúncios Google