design patterns elisabeth suescún leandra mara da silva

Design Patterns

Elisabeth Suescún

Leandra Mara da Silva

© LES/PUC-Rio

Motivação

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

Padrão Bridge (Handle/Body)

© 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

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

© 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

© 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

© LES/PUC-Rio

Bridge

• Motivação

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

© LES/PUC-Rio

Bridge

• Estrutura

© 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

© 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

design patterns elisabeth suescún leandra mara da silva

Documents