Design Patterns
Elisabeth Suescún
Leandra Mara da Silva
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.
© LES/PUC-Rio
Padrão Bridge (Handle/Body)
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
• Colaborações
– Abstraction repassa as solicitações dos clientes para o seu
objeto Implementor
© 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
© LES/PUC-Rio
Bridge
© LES/PUC-Rio
Bridge
© LES/PUC-Rio
Bridge
© LES/PUC-Rio
Bridge
© LES/PUC-Rio
Bridge
© LES/PUC-Rio
Bridge
© LES/PUC-Rio
Fim!!